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1.0 INTRODUCTION 



1.0 INTRODUCTION 


This report offers alternative concepts for a common design for 
the UARS and OPEN Central Data Handling facility (CDHF) (see Section 
4). The designs are consistent with requirements shared hy UARS and 
OPEN (Section 2 and Appendix 2) and the data storage and data process- 
ing demands of these missions (Section 3). Because more detailed 
information is available for UARS, the design approach has been to 
size the system and to select components for a UARS CDHF, but in a 
manner that does not optimize the CDHF at the expense of OPEN. Costs 
for alternative- implementations of the UARS designs are presented in 
Sections 4.1 and 4.2, showing that the system design does not restrict 
the implementation to a single manufacturer. Processing demands on 
the alternate UARS CDHF implementations are then discussed in Section 
4.3. With this intormation at hand together -with estimates for OPEN 
processing demands (Section 3.2.2), it is shown that any shortfall in 
system capability for OPEN support can be remedied by either component 
upgrades or array processing attachments rather than a system re- 
design. 

In addition to a common system design, it is shown in Section 5 
that there is significant potential for common software design, espe- 
cially in the areas of data management software and non-user-unique 
production software. 

The report then discusses archiving the CDHF data (Section 6). 
Following that, cost examples for several modes of communications be- 
tween the CDHF and Remote User Facilities are presented (Section 7). 
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The report concludes with a discussion of the potential application of 
technologies expected to reach fruition before the mission timeframe 
(Section 8), 
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2.0 UARS AND OPEN SYSTEM LEVEL REQUIREMENTS 

Based upon available documentation (see Bibliography) and input 
from GSFC technical personnel, a list of OPEN and UARS missions, sys- 
tem level requirements, assumptions and intercomparisons was generated 
(see Appendix A), in which particular emphasis was placed upon the 
Central Data Handling Facility (CDHF), It is seen that there are a 
number of system level functions common to both a UARS and an OPEN 
CDHF. The major of these common functions are: 

• Data ingest of playback data 

• Routine production processing of the data 

• Data management 

• Investigator communications. 

The distribution of these functions within the proposed CDHF concepts 
is defined in Section 4.0. 

2.1 UARS and OPEN Systems Elements 

Not only do the UARS and OPEN CDHF's share similar system level 
requirements, but their relations to institutional facilities are also 
similar. This is Illustrated in Figure 2.1-1. As shown in the 
figure, in addition to the CDHF, both the UARS and OPEN ground systems 
consist of the following functional elements: 

« Data capture 
« Orbit determination 

• Attitude determination 

• Command management 
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$ Payload operations control 

• Flight software 

• Mission planning 

• Comiaunications 

Additionally, the FI's will be provided interactive remote facilities 
suitable for analysis of the processed data. 

The main functions performed by the ground system elements as 
well as the inter-relationships among them are shown in Figure 2.1-1. 
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3.0 DATA STORAGE AND PROCESSING ANALYSES 


In order to derive system concepts for processing and managing 
data within the CDHF, estimates for their data storage and data pro- 
cessing requirements are necessary. These are presented in Sections 

3.1 and 3.2, respectively, 

3.1 PARS and OPEN Storage Analysis 

Information presented in the references (see Bibliography) allows 
for an analysis of the requirements for data processing and storage. 
It should be noted, however, that the information available for PARS 
is more complete. 

Tables 3.1-1 through 3.1-3 present .PARS data volumes for PARS 
production processing by data category. In addition, information 
regarding support data and PI data submissions from remote sites are 
included. 

Table 3.1-4 presents the OPEN storage requirements. These re- 
quirements have been derived from information presented in the pro- 
posals for the OPEN instruments which have been selected. 

3.2 PARS and OPEN Processing Estimates 

In order to derive system concepts for the CDHF, not only must 
the data requirements be at hand but it is also necessary to focus 
upon the magnitude of the processing demands upon the CDHF. These are 
presented for PARS and OPEN in the following two sections, respec- 
tively . 
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TABLE 3.1-1 DAILY UARS INSTRUMENT DATA VOLUME 



Avg. 

Daily Volume (MB) 


INSTROMEHT 

Dot a 
Rate 

Level 

Total 

Remarks 

' 

(Rbpo) 

0 

1 

2 

3 



Winds and Temperatures 
(WINTERS) 

1.3 

14 

14.5 

14.2 

2.8 

45.5 


High Resolution Doppler 
Imager (HRDI) 

4.5 

48-4 

86 

40 

0.6 

175.0 


Cryogenic Limb Array Etalon 
Spectrometer (CLAES) 

1.1 

1'2 

32 

10.9 

0.18 

45.08 


Halogen Occultation 
Experiment (HALOE) 

1.1 

15.8 

12.5 

2.7 

0,04 

31.04 


Improved Stratospheric and 
Mesospheric Sounder OlSAMS) 

0.5 

5.4 

2.7 

0.8 

3.3 

17.2 


Microwave Limb Scanner 
(MLS) 

4.0 

58.8 

90 

61 

31 

240.8 


Particle Environment 
Monitor (PEM) 

2.7 

28.5 

109.5 

11* 

5* 

154.0 

Levels 263 volumes 
are estimated from 
pi's requirements for 
graphics data. 

Solar Ultraviolet Spectral 
Irradiance Monitor (SUSIM) 

. I.O 

10.7 

0.5 

0.23 

0.01 

11.44 


Solar Stellar Irradiance 
Compar. Exper. (SOLSTICE) 

0.1 

0.7 

0.5 

0.5 

0.02 

1.72 


Solar Backscatter Ultra- 
violet Radiometer (SDOV)** 

0.32 

2.4 

2 

2 

0.4 

6.8 


(MAGNETOMETER) 

o 

0.3 

3.25 

6.5 

- 

- 

9.75 

Will be supplied by 
PEM and used in the 
PEM experiment only. 

TOTAL FROM ALL INSTRUMENTS 
(MB) 


199.95 

356.7 

133.33 

48.35 

738.33 



* 10:J decrease in data volume from LI L2 and 2:1 decrease from L2 -> L3 (estimated) 

** Similar to instrument flown on advanced TIROS-H Series. 
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TABLE 3.1-2 UARS INSTRUMENT ORIENTED STORAGE 

(Megabytes) 



PRODUCTION DATA 

OTHER 

DATA 


INSTROMEBT 

LO 

(10 DAYS) 

LI 

(30 DAYS) 

L2 

(540 DAYS) 

L3 

(540 DAYS) 

SUBTOTAL 

DATA SUBMISSIONS 
FROM REMOTES (>L3) 
(540 DAYS) 

MIMIMAL SUPPORT 
DATA 

mis 

(540 DAYS) 

WINTERS 

140 

435 

7,668 

1,512 

9,755 

0.0 

22.0 15] 

9,777 

HRDI 

484 

2.5B0 

21,600 

324 

24,988 

32.4 

0.1 

25,020 

CUES 

120 

960 

486 

97 

1,663 

9.7 

22.0 

1,695 

HALOE 

15B 

375 

1,458 

22 

2,013 

45.2 

3.1 

2,061 

ISAMS 

54 

81 

432 

4,482 

5,049 

540.0 

10.1 

5,599 

MLS 

38B 

2,700 

32,940 

16,740 

52,968 

8,141,4 

113.4 

61,223 

PEM 

317 Ul 

• 3,480 

5,940 

2,700 

12,437 

45.0 

22.0 f5l 

12,504 

SUSIM 

107 

15 

124 

5 

251 

0.1 

4.8 

256 

SOLSTICE 

7 

15 

270 

11 

303 

5.9 

0.3 

309 

SBUV 

24 

60 

1,080 

216 

1,380 

3.6 

22.0 15] 

1,406' 

Totals: 

1,999 

10,701 

71,998 

26,109 

110,807 

8,823.3 

219.8 

119,850 


Motes ; 

1. LO/day ° PEM L0(28.5) + Magnetometer L0(3.25) 

2. Ll/day = PEM Li(109.5) + MaEnctometer Ll(6.5) 

3. No estimate given; lOZ of L3 assumed 

4. Calibration processing coefficients, ground truth measurements, 
laboratory measurements, other correlative measurements 

. No estimate given; value assigned is average of 6 estimates that 
were given (1.3175 x 10® f 6 - 22 x 10®) 
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TABLE 3.1-3. UARS PRODUCTION DATA STORAGE REQUIREMENTS 


O 

-n 


"0 

O 

O 

33 

s> 


Production 
Data Type 

Sequential Days of Data 
Concurrently On-Line 

Daily Data 
Quantity 
(M Bytes) 

Concurrent On-Line Storage 
Requirements (M Bytes) 

; 

Archive 

Storage 

Requirements 

For 540 Days 

(M Bytes) 

On Shared 
Disk 

In MSS 

TOTAL 

On Shared 
Disk 

In MSS 

TOTAL 

L-0 

Ti t: . 

10 

10 

199.95 

- 

1,999 

1,999 

107,973 

L-1 

10 

20 

30 

356.7 

3,567 

. 7,134 

10,701 

192,618 

L-2 

10 

530 

540 

133.33 

1,333 

70,665 

71,998 

71,998 

L-3 

10 

530 

540 

48.35 

483 

25,625 

26,108 

26,109 

TOTALS 

738.33 

5,383 

105,423 

110,806 

398,698 


\ 

\ 
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TABLE 3.1-4 OPEN DATA STORAGE REQUIREMENTS 





PRINCIPH. IWESriGATOR (Pll 


0ofH.lrfc 

Duty 

Aierage 










S> 



Data Rate 

Cycle 

Data Rate 


Haae 

Or^iznion 

E^(penisenc 


nps 



1 


ICLA 

8i 

K»3. FI0£>S 


OJ 

10Q 

0.5 

5.4 

tiozer 

UCB 

85 

aK. FZEAS 


2.5 

SJ) 

90 

10 

2.75 

29.7 

Stskiian 

U of Icua 

25 

FUSKA UfVE 
INSTRJPBir 


CO 


16.64 

179.7 

Scudoer 

gsh: 

26 

K>T FUSW 

WDRA 

4.4 

ioqCSJ 

4.4 

47.5 

Sslle/ 

LFVJil. 

24 

HDTPLFSKA 

CWPOSRICN 


4.35 

loota 

4JS 

47.0 

Ctaptsl™ 

«FC 

31 

CCL6 PUSKA 

TIDE 

2.5 

laica 

2.5 

27.0 


LASL 

43 

a£c. pAmciE 

cavAD 

3.2 

90 







9.6 

10 

3.84 

41.47 

fr,tz£'3 

NOAA/£a. 

S3 

a£C. PA8nO£ 

CfftU{£ 

1.152 

ICO 

1.152 

12.45 




cczfostnoN 





Fel<ten 

JHi 

SO 

VlSiaE IHVER 

HAID 

16.2 

eo 

12.96 

140.0 

Terr 

Utah 

92 

LV UWER 

AI>E 

TOD 

TOD 

20 

216.0 

Jetof 

LfARL 

64 

XHUy 1H>££R 

PIXIE 

3J> 

eo 

2.4 

25,92 







LT6 total 

71.49 

772.1 

fcfterroo 

UCLA 

66 

tw. ri£us 


0.S 

ICO 

0.5 

5.4 

>feyrert 

6SFC 

59 

B£C. Flans 


1.4 

2.0 

90 

to 

1.46 

15.8 

Kcllwatn 

UCSD 

74 

H0TF1.AS>tt 

EFians 

2.0 

ICO 

2.0 

21.6 


th; 

91 

PLASKA UATE 


2.138 

90 

2.54 

27.44 




llISTRJKHr 


6.1 SB 

ID 

. Parks 

U of Uas6. 

19 

HOT FUSMA 


a.2 

iaP3 

8.2 

88.56 


SU 

45 

HIT FUSHA 


2.0 

to 

0.25 

2.7 




consincH 


5.0 

1 


yesf 

31 

flUFLASHA 

TIDE 

2.5 


2-5 

27.0 

1 Hicoie*-*-^ 

USL 

43 

RFC. PMTlCtf 

tSfAD 

3.2 

9.6 

90 

to 

3.84 

41.47 

1 

i 

NOM/SEL 

53 

PMTICLE 

CM1UCE 

1.464 

ICO 

1.464 

15.8 




COfOSmON 











ue TOTAL 

22.75 

245,7 

L'tping 

GSFC 

33 

KAS. Fians 


0.65 

3.7 

90 

10 

0.955 

10J1 


UCB 

84 

aEc. Fms 


0.6 

90 

0.66 

7.1 






1.2 




Gurrett 

U of Icwa 

46 

FLASrV^UAVE 


1.174 

100 

1.674 

18.08 




10J) 

5 



Frark 

U of loa 

77 

«T RJQIA 

tS^A 

3.5 

1DO 

3.S 

37J 


PAH.Y DATA VOJJ€ 0& 


UIC. PmiCt£ 
cwosmaj 



A7.0 U1.0 

Z7.0 ei.Q 


140.0 420.0 

216.0 643.0 


25.92 77.76 


7.47 57.27 


3.24 24.84 

9.48 72.68 



27.0 81.0 

41.47 124.4 




C^ilvie 

GUsekUr 

GSFC 
U of Ki 

50 

as 

lOT fL«PA . 
K)T RJISKA 

cctromcN 


0.^ 

0.471 


o.co 

0.471 

4.32 

5.0B 

Lin 

UCB 

13 

a£C. PARTICLI 


0.383 

1GcP3 

0.3SD 

4.10 


GSFC 

54 

C0941C rats 

B^fCT 

0.25 

100 

0.25 

2.7 

Teegyben 

GSFC 

23 

GfftU RATS 


0.193 

1DQ 

0.195 

2.CB 







U8 TDTFL 

3.81 

41.1 






TOTALS FOR Aa FOUR LFBS 

1C7.54 

1,161.3 



On-Line 

Stenge 

Off-Line 

Storage 

Reqjireaent 

re™ 

1,944 

18,133.2 

10/92 

99,732/ 

64/92 

605/32.6 

17,100 

159/05/ 

16,920 

157/26/ 

9,720 

90/66.0 

14,928 

139/47/ 

4/82 

41/CF.I 

'50,«0 

77,760 

«;o,i 20 .o 

725/28.0 

9/31 

87,159.9 

277,956 

2/56,711/ 

1,944 

^,199/ 

5/83 

79,584.6 

7,776 

1CB,799.2 

9/78 

138/10.9 

31/82 

446/61.1 

972 

13/99.9 

9,720 

135,999.0 

14,968 

2C8/7I/5 

5/83 

79,584/ 

88/52 

1,237,550.9 

3,711 

51,9E4.9 

2/56 

35,762.7 

6,50? 

91,071.15 

13/08 

190/93,6 

10/97 

146/72/5 

36/64 

515,788/ 

3,711 

51,524.9 

4/0? 

63/61.05 

1,555 

21,757,65 

1/29 

25/50.15 

1,476 

972 

20/S1.7 

13/99.9 

749 

10/79.15 

14,796 

207,020,7 

418/068.0 

4/53,112/ 




LM Repeats CQ 1,5 Kbps £f lOtK diity cycle; Z5.2 Kbps a 100?{; 

ra A^umed ^ 128 Kbps 0 5% <256 Kbps fcr 30 minutes; 

or 25,6 KHz for 4 hcxjrs) 


M Increase of 3:1 frao ID — > LI (assumed) 
ra Decrease of 5:1 from t1 — > 12 (assumed) 

16} 100 Days LI + 100 Days L2 

ro 36 rKTiths each for &L, GTL, IFL; 24 months of FPL 
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3.2.1 UARS Processing Esti-matp-s 

Based upon the data processing requirements contained in the 
actual questionnaire responses submitted by the Pis and the CSC study 
which summarizes and synthesizes these responses (References 6 and 7 
of the UARS Bibliography), it is estimated that in order to process a 
day's data for the instruments selected (Appendix b) a total load of 
about 97,000 seconds of processing (excluding I/O) is required for 
computing machinery with an effective throughput of 0.5 Million Float- 
ing Point Operations (MFLOPS) per second. Thus, 

0.5 MFLOPS X 97,000 sec = 48,000 MFLOPS 

sec " 

are estimated for a day’s production run. If these operations could 
be spread uniformly over, an 8-hour period (one shift) then the effec- 
tive throughput of the computing machinery would be: 

48,500 MFLOPS x _1 x 1 hr = 1.68 MFLOPS/ sec, 

8 hr 3600 sec 

In other words, CPU sizing for processing should be in the 2 MFLOPS/ 
sec (effective throughput) range. Note that I/O and data management 
demands are not included. 

3.2.2 OPEN Processing Estimates 

Information for OPEN data processing which is comparable to the 
results in the CSC study has not yet been developed. However, gross 

estimates can be made for OPEN by extrapolating what is known about 

\ 

UARS together with analyzing the selected OPEN instrument proposals. 
When this is done, it is estimated that CPU sizing for OPEN data pro- 
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cessiag is about in the 9 MFLOPS/sec range (effective throughput), 
excluding I/O and data manageiaent demands. The analysis for deriving 
this number is as follows: 

For TJARS the data being "transformed" during routine production 
processing are L-0, L-1 and L-2 which are transformed into L-1, L-2 
and L“3, respectively. For OPEN, L-0 and L-1 data are transformed 
into L-1 and L-2, respectively. The daily quantity of data being 

i 

transformed is as follows: 

UARS: L-0 + L-1 + L-2 = 690 MB/day 
OPEN: L-0 + L-1 = 4645 Iffi/day 

See Tables 3.1-1 and 3.1-4, respectively. 

For UARS, transforming the- following instruments' L-1 data into 
L-2 accounts for about 91% of the total routine production processing 
demands: MLS, HALOE, ISAMS, CLAES, and WINTERS. Their associated 

quantity of L-1 data transformed daily is 151.7 Mbytes (see Table 
3.1-1), which represents 151.7/690 = 22% of the total data which is 
transformed. These instruments were chosen as candidates for array 
processing. (Their processing demand estimates are reflected in the 
analysis presented in Section.i4;3.) 

For OPEN, five instruments are chosen as having similar process- 
ing demands as the TJARS instruments indicated in the previous para- 
graph. These are the instruments of Feldman, Torr, Scarf, Gurnett, 
and Ogilvie. Their associated quantity of L-1 data transformed daily 
is 798 MB (see Table 3.1-4), which represents 798/4645 = 17% of the 
total data to be transformed. Note that this is comparable to the 
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analogous UARS percentage. The following assumptions are therefore 
made : 

c 

• Al) Transforming the L-1 data of the preceding 5 OPEN instru- 
ments will account for about 90% of the OPEN routine pro- 
cessing demands. 

A2) The processing demands for transforming the L-1 data of the 
preceding 5 OPEN instruments is about 798/152 = 5.25 times 
the processing demands for transforming the L-1 data of the 
5 UAE.S instruments listed previously. 

From Section 3.2.1, it was estimated that CPU sizing for UARS 
production processing is a minimum of 1.68 MFLOPS/ sec (effective 
throughput).- Thus, about 90% of 1.68 MFLOPS = 1.51 MFLOPS/sec are 
required to process the 151.7 MB of L-1 data of the selected UARS 
instruments. Therefore, from Assumption 2, 5.25 times 1.51 = 7.93 
MFLOPS/sec would be required to process the analogous 798 MB of OPEN 
data. Adding 10% for the remaining production processing yields an 
estimate of 7.93 + 0.79 = 8.72 MFLOPS/sec to process a day's worth of 
OPEN data in an eight-hour period, excluding I/O and data management 
demands. The ratio of OPEN processing demands to UARS processing 
demands is 8.72:1.68 = 5.2:1. 
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4.0 CDHF SYSTEM CONCEPTS 



4.0 CDHF SYSTEM CONCEPTS 


This section presents two system design approaches for satisfying 
the requirements of either a UARS or an OPEN CDHF* Because the UARS 
CDHF is assumed to precede the OPEN CDHF, the overall approach has 
been to size a system and select components for a UARS CDHF, but in a 
manner that does not optimize the CDHF for UARS at the expense of 
OPEN. Indeed, the shortfall in system capability for OPEN support 
could be remedied by component upgrades rather than by a system re- 
design. 

In what follows, a detailed analysis is made for UARS. System 
upgrades to accommodate OPEN are discussed in Section 4.4. 

Based upon available information, the following major UARS func- 
tions have been identified: 

• Data Ingest and L-0 Production 

• L-0 to L-1 Production 

• L-1 to L-2 Production 

• L-2 to L-3 Production 

• Data Services To/From Remotes 

- Browsing 

- Data File Transfers-’ - 

• Remote Batch 

- Scheduling 

- Services 

• Data Management 

Based upon these functions, two functional concepts for a UARS CDHF 
have been formulated. The first concept presented is a CDHF featuring 
dual mainframe systems. The second concept presented is a CDHF .confi- 
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guration featuring a single mainframe system. Neither concept depends 
upon unique hardware subsystems available from only a single vendor. 
The dual mainframe and single mainframe concepts are described in 
Sections 4,1 and 4.2, respectively, and two different hardware imple- 
mentations of each concept are presented. Summary information regard- 
ing significant features and costs are presented in Tables 4.0-1 and 

4.0- 2. 

4.1 Dual Mainframe Concept 

In the dual mainframe concept the various CDHF functions are 
carried out by two autonomous software compatible mainframes which 
share a common database, and the CDHF functional workload is split be- 
tween a Production Processor (PP) system and a Data Manager/Processor 
(DM/P) system as illustrated in Figure 4.1-1, As indicated in Figure 

4.1- 1, the extensive arithmetic and matrix manipulation services re- 
quired to accomplish daily L-2 production and to provide remote batch 
services are provided by the PP and its associated array processing 
facilities, while the computationally less demanding L-0, L-1 and L-3 
production services, as well as the (primarily) non-arithmetic data 
ingestion, data management ,and..remote site interface services are 
provided by the DM/P. 

The PP and DM/P would be sized to permit the processing of a 
day's volume of UARS data in one work shift, with capacity to spare. 
The PP would be sized in the 3 to 3.5 MIPS range, while the less 
powerful DM/P would operate in the range of 1 MIPS. 

Since the dual mainframe concept features two independent soft- 
ware compatible mainframes sharing a common database, certain backup 
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TABLE 4.0-1 


ALTERNATE IMPLEMENTATION FEATURE SUMMARY 


DVAL MAINFRAHE IHFLEMENTATIOH 

SINGLE MAINFRAME IMPLEMENTATION 



IBH^^I 


* Production Processor 

* Production Processor 



o IBM 3033-N-8 

a CDC Cyber 170 Series 700 



- 8 Mbyte Memory 

170-730 Dual Processor 



- 3 MIPS 

- 262K X 60 Bit Memory 




- 3.5 HIPS 





^ System Processor 

* System Processor 

a 2 FPS AP-109I, Array 

• CDC Advanced Flexible 

a IBM 3081 

a CDC Cyber 170 Series 700 

Processors 

Processor (For Array 

- 16 Mbyte Memory 

170-760 Processor 

— 6 MFLOPS Average (ea) 

Processing) 

- 10.6 MIPS 

- 262K X 60 Bit Memory 

" 256K Memory (ea) 

- 200 Million Arithmetic 


- 11 HIPS 


Operations/Second (Avg) 



1 



o Extended Memory 

‘ 



- 1 Million 60 Bit Words 

* Data Managar/Production 

* Data Managor/Produetion 



Processor 

Processor 



a IBM 63AI-L02 

• CDC Cyber 170 Series 700 



- 8 Mbyte Memory 

170-720 Processor 



- 0.75 MIPS 

— 262R X 60 Bit Memory 




- 1.2 MIPS 




* Shared Extended Memory 




a I Million 60 Bit Words 



* On-Line Mass Storage^ 

* On-line Hass Storage^^^ 

* On-Line Hose Storage^ 

* On-Line Mass Storage^^^ 

(Shared, not disk) 

(shared, not disk) 

(not disk) 

(not disk) 

■ a 2 IBM 3851-A04 

a 2 MASSTOR 860 

a 2 IBM 3851-A06 

a 2 HASSTOR H860 

“ 472 Gbytes Total 

- 440 Gbytes Totol 

- 472 Gbytes Total 

- 460 Gbytes Total 


Botes: 


m 

[21 

13 ] 

141 

[51 

[61 


Partial lioting; coispLate Hating in 
Partial listing; complete listing in 
Partial Listing; complete listing in 
Partial listing; complete listing in 
System limit; may not be e3<patided» 
Expendable • 


Table 4.1-3. 
Table 4.1-6, 
Table 4.2-3. 
Table 4.2-5, 
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TABLE 4.0-2 


SYSTEM COST SUMMARY ESTIMATES 


FACILIXY 

DUAL MAINFRAME IMPLENENTAtlOH 

SINGLE MAINFRAME IMPLEMENTATION 




CDC^^l 

Central Data Handling 
Facility (CDHF) 

$8,463,662 

$7,405,105 

$9,539,135 

$8,236,388 

Software Coiapatible 
Remote SiteMSl 
(1 site/19 sites) 

$208,890/ 

$3,968,910 

$747,837/ 

$14,208,903 

$208,890/ 

$3,968,910 

$747,837/ 

$14,208,903 

Combined Cost of CDHF 
and 19 Remote Sites 

$12,432,572 

$21,614,008 

$13,508,045 

$22,445,291 


Notes : 


[1] 

Detailed 

cost 

estimates 

presented 

in 

Tables 

4.1-3 

and 

4.1-4. 

[2] 

Detailed 

cost 

estimates 

presented 

in Tables 

4.1-6 

and 

4.1-7. 

[31 

Detailed 

cost 

estimates 

presented 

in 

Tables 

4.2-3 

and 

4.1-4. 

[4] 

Detailed 

cost 

estimates 

presented 

la 

Tables 

4.2-5 

and 

4.1-7. 


[5l CDC remote facilities have extensive computational capabilities appropriate 
for OPEN. IBK remote facilities, while less powerful, are more appropriate 
for UARS. The CDC remote facilities represent the low end of the software 
compatible Cyber 170 Series 700 equipment llne« 
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capabilities are inherent in this approach which are not present in a 
single mainframe approach. In the event of PP outage, the DM/P and 
array processing facilities may be used to carry on PARS production at 
a reduced rate of approximately 50% (2 work shifts, with little or no 
margin). In the event of DM/P outage, the PP can assume the responsi- 
bilities of the DM/P and complete all daily processing tasks within 2 
work shifts. 

Two possible hardware implementations of the dual mainframe con- 
cept have been prepared. The first implementation features dual IBM 
mainframes (Section 4.1.1), while the second implementation features 
dual GDC mainframes (Section 4.1.2). Table 4.1-1 summarizes these two 
implementations . 

4.1.1 An IBM Hardware Implementation 

This implementation of the dual mainframe concept is configured 
using hardware produced by the IBM Corporation and Floating Point 
System (FPS) Corporation. See Table 4,1-2, Figure 4.1-2 presents the 
general structure of this implementation, A more detailed illustra- 
tion of this implementation is presented in Figure 4,1-3. 

Cost summary inform ation-f or an IBM dual mainframe CDHF and the 
corresponding remote (PI) facilities is presented in Tables 4.1-3 and 
4.1-4, respectively. 

4.1.2 A CPC Hardware Implementation 

This implementation of the dual mainframe concept is configured 
using hardware produced by Control Data Corporation (CDC) and Masstor 
Systems Corporation. See Table 4.1-5. Figure 4.1-4 presents the 
general structure of this implementation. 
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TABLE 4.1-1 


DUAL MAINFRAME IMPLEMENTATIONS 


Feature 

IBM 

CDC 

Production Processor (PP) 

; 

IBM 3033-N-8 

CDC Cyber 170 
170-730 Dual 
Processor 

Data Manager/ Production 
Processor (DM/P) 

IBM 4341 -LO 2 

CDC Cyber 170 
170-720 Processor 

Array Pro cess or (s) 

2 Floating Point Systems 
AP-190L Array Processors 

CDC Advanced 
Flexible Processor 

Inter-Processor Data 
Exchange 

Shared Disk 

Shared Disk 

Dedicated Separate System 
Disks 

Yes 

No 

Mass Storage Facilities 
(other than disk) 

IBM 3850 

(472 Billion Bytes) 

MASSTOR M-860 
(440 Billion Bytes) 

PP and DM/P Software 
Compatibility 

Yes 

Yes 

























TABLE 4.1-2 


AN IBM DUAL MAINFRAME SUBSYSTEM SUMMARY 


Subsystem. 

Manufacturer 

Comments 

Mainframe Processors 

IBM 

PP: Model 3380-N-8 

DM/P: Model 4341 -LO 2 

Tape 

IBM 

2 Drives /Mainframe 

Disk 

IBM 

1,2 Gbytes (not shared)/ 
Mainframe; 

lOil Gbytes shared be- 
tween mainframes 
(approximately 50% 
used for recent pro- 
duction data) 

Communications 

IBM 

dm/p Subsystem 

CDHF Terminals 

IBM 

5 CRT Terminals and 
2 Printers /Mainframe 

Array Processor 

Floating Point 
Systems 

Off-the-shelf interface 
software readily avail- 
able 

On-Line Mass Storage 

IBM 

Shared; cannot be ex- 
panded beyond 472 Gbyte 
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TABLE 4.1-3 


COSTS OF AN IBM DUAL MAINFRAME CDHF IMPLEMENTATION 


ITEM GSA PURCHASE PRICE ($) 

PRODUCTION PROCESSOR (PP) 

• IBM-3033-N-8 1,561,000 

- 3 MIPS 

- 8 Mbyte Memory 

- 12 Channels 

- Power Unit 
Operator Console 

• Array Processors 352,000 

- 2 FPS AP-190L 

- 6 MFLOPS Average (each) 

“ 256 K Memory (each) 

• PP Disks 268,360 

- 1 .2 Billion Bytes 

- 1 3880-003 Controller 

- 1 3880-A04 Disk 

- 1 3880-B04 Disk 

9 PP Tapes 85,175 

- 1 3803—002 Controller 

- 2 3420-006 Tape Units 
(125 ips, 1600/6250 bpi) 

9 Terminals 40,524 

- 1 3274 Control Unit 

- 5 3278 KB/CRT' s 

- 2 3287 Printers (friction feed) 

s Line Printer 41-,250 

- 1 3203-005 (1200 1pm, train cartridge) 


PP TOTAL COST 2.348.309 
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TABLE 4.1-3 CCon.tin.ued) 


COSTS OF AN IBM DUAL MAINFRAME CDHF IMPLEMENTATION 

ITEM GSA PURCHASE PRICE ($) 

DATA MANAGER AND PROCESSOR (DM/P) 

• IBM-4341-L02 497,000 

- 8 Mbyte Memory 

- 0.75 MIPS 

• DM/P Disks 268,360 

- 1.2 Billion Bytes 

- 1 3880-003 Controller 

- 1 3380-A04 Disk 

- 1 3380-B04 Disk 

• DM/P Tapes 85,175 

- 1 3803-002 Controller 

- 2 3420-006 Tape Unit s 
(125 ips, 1600/6250 bpi) 

© Terminals 40,524 

-- 1 3274 Control Unit 

- 5 3278 KB/CRT' s • 

- 2 3287 Printers (friction feed) 

• Line Printer 41,250 

- 1 3203-005 (1200 1pm, train cartridge) 

• Communications - 86,890 

1 3705-F04 (24 Bi-sync lines @ 9.6 Kbps) 

DP/M TOTAL' COST 1.019.199 
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TABLE 4,1-3 (Concluded) 


COSTS OF AK IBM DUAL MAINFRAME CDHF IMPLEMENTATION 


ITEM GSA PURCHASE PRICE ($) 

SHARED SUBSYSTEMS 

• Disk 1,721,440 

- 10.144 Billion Bytes (Total) 

- 2 3880-03 Controllers 

- 4 3380-A04 Disks 

- 12 3380-B04 Disks 

• Mass Storage System 3,374,714 

- 472 Billion Bytes (Total) 

2 3851-A04 Mass Storage Facilities (MSF) 

236 Billion Bytes (each MSF) 

4 Data Recording Controls (each MSF) 

8 Data Recording Devices (each MSF) 

4720 Cartridges (each MSF) @ $35 each 

- 2 3830-003 Storage Control Units 

- 2.536 Billion Bytes Staging Disk 
(2 3350-A02, 2 3350-B02) 


SHARED SUBSYSTEM COST 5,096,154 


CDHF TOTAL COST 8,463,662 
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TABLE 4.1-4 


COSTS FOR IBM COMPATIBLE REMOTE FACILITIES 


ITEM 

« 1 IBM-4331-101 

- 512 KB Memory 

- 0.5 MIPS 

- 600 MB Disk Storage 

- Commuiiicatioii Adapters 

• 1 Graphics Terminal 
(Tektronics 4012) with 
Hardcopy Device 
(Tektronics 4631) 

• 2 Magtape Controller and 
Tape Units 

- 800/1600 bpi 

• 3 Consoles 

- 1 OP. Console 

- 2 Alphanumeric Terminals 

9 1 400 1pm Printer (IBM-3289) 



30,000- 


40 ,000 


7,000 


13,140 


TOTAL COST for 1 System 
TOTAL COST for 19 Systems 
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TABLE 4.1-5 


A CDC DUAL MAINFSAME SUBSYSTEM SUMMARY 




Subsystem 

Manufacturer 

CoBuaents 

Mainframe Processors 

CDC 

PP: Series 700 170-730 

Dual Processors 
DM/P: Series 700 170- 

720. 

Tape 

CDC 

4 Drives (shared) 

Disk 

CDC 

13.8 Billion 6 bit char- 
acters (shared); appro- 
ximately 50% used for 
recent production data 

Communications 

CDC 

Shared 

CDHF Terminals 

CDC 

10 Shared CRT Terminals 
and 4 Shared Printers 

Array Processor 

CDC‘ 

Advanced Flexible 
Processor (AFP) 

On-Line Mass Storage 

MASSTOR 

Shared; M-860 systems 
marketed and supported 
by CDC; expandable 
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A more detailed illustration indicating the extensive dual access 
features of this implementation is presented in Figure 4.1-5. 

Cost summary information for a CDC dual mainframe CDHF and the 
corresponding remote (PI) facilities is presented in Tables 4.1-6 and 
4.1-7, respectively. 

4.2 Single Mainframe Concent 

The single mainframe concept accomplishes all of the CDHF func- 
tions using a single large mainframe. This concept is illustrated in 
Figure 4.2-1. 

As was the case with the dual mainframe concept, the single main- 
frame is sized to permit the processing of a day's volume of UARS data 
in one work shift. In contrast to the dual mainframe concept, how- 
ever, the single mainframe concept does not include the capability to 
operate at reduced levels in the event of mainframe failure since 
there is no mainframe* redundancy. 

Sections 4.2.1 and 4.2,2 present hardware implementations of the 
single mainframe concept. A possible IBM implementation is described 
in Section 4.2.1, while Section 4.2.2 presents possible GDC implemen- 
tation. Table 4.2-1 summarizes'-several features of these implementa- 
tions. 

4.2.1 An IBM Hardware Imt> lament at ion 

Table 4,2-2 summarizes several features of this all IBM system, 
while Figure 4.2-2 presents the general structure of this implementa- 
tion. Figure 4.2-3 provides a more detailed illustration showing 
peripheral/channel relationships and device/controller cross-strapping 
for this implementation. 
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TABLE 4.1-6 


COSTS OF A CDC DUAL MAINFRAME CDHF 


ITEM 

PRODUCTION PROCESSOR (PP) 

fi CDC Cyber 170 Series 700 
170-730 Dual Processor 

- 3.5 MIPS 

- 60 Bit Word 

- 262R. Word Central Memory 

- 24 Channels 

- 17 Peripheral Processors 

- Extended Memory Interface 

- Power Unit 

- Operator Console 

• Array Processor 

- CDC Advanced Flexible Processor 

- 200 Million Arithmetic 
Operations/Seconds (AVG) 

9 Terminals 

- 5 Alphanumeric CRT's (CDC 722-10) 

- 2 Desktop Printers (CDC 755-20) 

9 Line Printer 

- 1200 1pm (CDC 580-12) 

Printer Train Cartridge (CDC 596-6) 


PP TOTAL COST 


IMPLEMENTATION 

GSA PURCHASE PRICE ($) 

1,236,910 


400,000 

13,490 

60,187 

1,710.587 
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TABLE 4.1-6 (Continued) 


COSTS OF A CDC DUAL MAINFRAME CDHF 


ITEM 

DATA MANAGER AND PROCESSOR (DM/P) 

• CDC Cyber Series 700 
170-720 Processor 

- 1.2 MIPS 

- 60 Bit ¥ord 

- 262K Word Central Memory 

- 24 Data Channels 

- 17 Peripheral Processors 

- Extended Memory Interface 

- Power Unit 

- Operator Console 

• Terminals 

- 5 Alphanumeric CRT's (CDC 722-10) 

- 2 Desk Top Printers (CDC 755-20) 

• Line Printer 

- 1200 1pm (CDC 580-12) 

- Printer Train Cartridge (CDC 596-6) 


DM/P TOTAL COST 


IMPLEMENTATION 

GSA PURCHASE PRICE ($) 

801,535 


13,490 

60,187 

875.212 
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TABLE 4.1-6 (Continued) 


COSTS OF A CDC DUAL MA.INFRAME GDEF 


ITEM 

SHARED SUBSYSTEMS 
« Extended Memory 

- 1 Million 60 Bit Words 

- 3 High Speed Ports 

- 10-20 Million Words/Second 

6 Disk (GDC) 

- 13.84 billion 6-bit characters 

- 10 885—12 Disk Storage Units 
(dual spindle, two-controller) 

- 4 7155-12 Two Channel Controllers 

- 4 7155-885 Four Drive Expansion 

• Tape (CDC) 

- 4 679-7 Tape Transports 
(200 ips, 1600/6250 bpi) 

- 1 7021-32 Dual Access Controller 

• Mass Storage System (MASSTOR) 

- 440 billion bytes 

- 8 M861 Mass Storage Modules 
(16 read/write stations) 

- 2 M862 Dual Access Storage 
Controllers 

- 4 Channel Couplers (CDC 65206-X) 


SHARED SUBSYSTEM TOTAL COST 


IMPLEMENTATION 

GSA PURCHASE PRICE ($) 

663,200 

881,360 

224,040 

2,911,800 

4.680.400 
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TABLE 4,1-6 (Concluded) 


COSTS OF A CDC DUAL MAINFRAME CDHF IMPLEMENTATION 


ITEM GSA PURCHASE PRICE ($) 

COMMUNICATIONS 

• 2 Dual Access Subsystems 138,906 

- 2 CDC 2551-2 Network Processing 
Units (NPU) 

96K 16-bit words /NPU 

2 558-3 Couplers /NPU 

6 Sync. Comm Line Adapters (CLA) 
per NPU (2 Remote Lines /CLA) 

3 Async, CLA' s per NPU 
(2 Local CRT's/CLA) 

- Remote Site Interface 

22 Bi-sync Lines (11/NPU) 

9600 bps 

- PP CRT Terminal Interface (Hardwired) 

5 Asynchronous Lines 

9600 bps 

- DM/P CRT Terminal Interface (Hardwired) 

5 Asynchronous Lines 

9600 bps 


CDHF TOTAL COST 


7.405.105 



TABLE 4.1'7 


COSTS FOR CDC COMPATIBLE REMOTE FACILITIES 


ITEM GSA PURCHASE PRICE ($) 

• 1 CDC Cyber 170 Series 700 479,545 

170-720 Processor 

- 1.2 MIPS 

- 60 Bit Word 

- 98K Word Central Memory 

- 10 Peripheral Processors 

- Power Unit 

- Operator Console 

® Disk Subsystem 99,890 

- 1 7155-11 Disk Controller 

- 1 885-11 Dual Spindle Disk Storage Unit 
(1.384 billion characters) 

e Ta.pe Subsystem 81,720 

- 1 7021-31 Tape Controller 

- 2- 679-2 Tape Transports 
(800/1600 bpi, 100 ips) 

6 Line Printer 17,000 

. - 1 1827-60 (600 1pm) 

• 2 Terminals 3,000 

- 2 Alphanumeric CRT's (CDC 722-10) 

- Installation Charge 

e 1 Graphics Terminal 30,000 

(Tektronics 4012) with 
Hardcopy Device 
(Tektronics 4631) 
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TABLE 4.1-7 (Concluded) 

COSTS FOR CDC COMPATIBLE REMOTE FACILITIES 


ITEM GSA PURCHASE PRICE ($) 

• Communications and Terminal Control 36,682 

- CDHF Interface 

- Local Alphanumeric (2) CRT Interface 

- Local Graphics Terminal Interface 

- 1 CDC 2551-1 Network Processing Unit 
(32K 16-bit word memory) 

- 1 CDC 2580-4 Autostart Module-Gas sette 

- 1 Synchronous Comm, Line Adapter (2 Lines) 

(CDHF Interface, Graphics Terminal Interface) 

- 1 Asynchronous Comm. Line Adapter (2 Lines) 

(Local Alphanumeric CRT Interface) 


TOTAL COST for 1 System 


747.837 


TOTAL COST for 19 Systems 


14.208.903 
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FIGURE 4.2-1 SINGLE MAINFRAME FUNCTIONAL CONCEPT 
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TABLE 4^2^i 

SINGLE MAINFRAME IMPLEMENTATIONS 


Feature 

IBM 

GDC 

System Processor 

IBM 3081 

GDC Cyber 170 
170-730 
Processor 

&.rray Processor 

None 

None 

Mass Storage (other 
than disk) 

IBM 3850 (472 
Billion Bytes) 

M^SSTOR M-860 (440 
Billion Bytes) 


4-26 













TABLE 4.2-2 


AN IBM SINGLE MAINFRAME SUBSYSTEM SUMMARY 


Subsystem 

Manufacturer 

Comments 

Processor 

IBM 

Model 3081 

Tape 

IBM 

4 Drives 

Bisk 

IBM 

10,1 Gbytes; approxi- 
mately 50% used for 
recent production data. 

Communications 

IBM 


CBHF Terminals 

IBM 

10 CRT Terminals 
and 4 Printers 

Array Processor 


None 

On-Line Mass Storage 

IBM 

Cannot be expanded 
beyond 472 Gbyte 
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FIGURE 4.2-2 AN IBM SINGLE MAINFRAME STRUCTURAL SUMMARY 
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FIGURE 4.2-3 AN IBM SINGLE MAINFRAME IMPLEMENTATION 
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Cost summary information for the IBM single mainframe implementa- 
tion is presented in Table 4.2-3« Costs for software compatible 
remote facilities are the same as those presented for the IBM dual 
mainframe system (see Table 4.1-4). 

4.2.2 A CPC Hardware Implementation 

Major elements of this CDC implementation are presented in Table 
4.2-4. The major subsystems are illustrated in Figure 4.2-4. A de- 
tailed illustration of a possible CDC single mainframe CDHF implemen- 
tation is presented in Figure 4.2-5. 

Cost summary information for the GDC single mainframe CDHF is 
presented in Table 4.2-2. Costs for corresponding remote (PI) facili- 
ties would be as presented in Table 4.2-5. 

Another option for a CDC single mainframe implementation would be 
to replace the 170-740 mainframe with a less powerful 170-740 pro- 
cessor and aray processing facilities (the CDC Advanced Flexible 
Processor), In contrast to the 170-760 processor, which operates in 
the range of 10-12 MIPS, the 170-740 operates in the range of 4.5 to 5 
MIPS; the Advanced Flexible Processor (AFP) operates in the range of 
200 million arithmetic operations per second. 

The total cost of the 170-740 /AFP system would be $6,931,788 in 
contrast to the $8,236,388 cost of a 170-760 total CDHF system. While 
this cost difference of $1,304,600 is not trivial, the introduction of 
array processing facilities external to the mainframe processor could 
increase software development costs at the CDHF and, especially, at 
the remote sites (which are not- scheduled to have special array pro- 
cessing facilities). 
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TABLE 4.2-3 


COSTS OF A IBM SINGLE MAINFRAME CDHF IMPLEMENTATION 


ITEM 

• IBM 3081 Processor 

- 10.4 MIPS 

- 16 MByte Memory 

- 16 Channels 

- Power Unit 

- Coolant Distribution Unit 

- Operator Console 

• Disk 

- 10.144 Billion Bytes (Total) 

- 2 Disk Subsystems (DSS) 

- Each DSS 

2 3880-003 Controllers 
2 3380-A04 Disks 
6 3380-B04 Disks 

» Tape 



- 4 3420-006 Tape Units 
(125 ips, 1600/6250 bpi) 

- 2 3803-002 Control Units 

- 1 3803-1792 Two Control Switching Option 

• Mass Storage System 3,374,714 

- 472 Billion Bytes (Total) 

2 3851-A04 Mass Storage Facilities (MSF) 

236 Billion Bytes (each MSF) 

4 Data Recording Controls (each MSF) 

8 Data Recording Devices (each MSF) 

4720 Cartridges (each MSF) @ $35 each 

- 2 3830-003 Storage Control Units 

- 2.536 Billion Bytes Staging Disk 
(2 3350-A02, 2 3350-B02) 
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TABLE 4.2-3 (Concluded) 

COSTS OF A IBM SINGLE MAINFRAME CLEF IMPLEMENTATION 


ITEM 


GSA 


• Terminals 

- 1 3274-D31 Control Unit 

(1 each 6901, 6902 Adapters) 

- 10 3278-002 KB/CRT' s 

- 4 3287-002 Printers 
(Friction Feed) 

• Line Printers 

- 2 3203-005 

(1200 1pm, train cartridge) 
a Communications 

- 1 3705-F04 

(24 Bi-sync lines @9.6 Kbps) 


CDHF TOTAL COST 


PURCHASE PRICE ($) 
62,367 


82,500 

86,890 

9.539.135 
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TABLE 4,2“4 


A GDC SINGLE MAINFRAME SUBSYSTEM SUMMARY 


Subsystem 

Manufacturer 

Gomments 

Processor 

GDC 

Series 700 170-760 

Tape 

GDC 

4 Drives 

Bisk 

GDC 

13.8 Billion 6 bit char- 
acters; approximately 
50% used for recent pro- 
duction data. 

Communications 

CDG 


CDHF Terminals 

GDC 

10 GRT Terminals 
and 4 Printers 

Array Processor 


None 

On-Line Mass Storage 

CBC 

M-860 systems marketed 
and supported by CBC; 
expandable 
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TABLE 4.2-5 


COSTS OF A CDC SIHGLE MAINFRAME CDHF IMPLEMENTATION 


ITEM 

• CDC Cyber 170 Series 700 
170-760 Processor 

- 11 MIPS 

- 60 Bit Word 

- 26 2K Word Central Memory 

- 24 Channels 

- 20 Peripheral Processors 

- Extended Memory Interface 

- Power Unit 

- Operator Console 

9 Extended Memory 

- 1 Million 60 Bit Words 

- 10 Million Words /Second 

• Disk (CDC) 

- 13.84 billion 6-bit characters 
10 885-12 Disk Storage Units 
(dual spindle, two-controller) 

- 4 7155-11 Controllers 

- 4 7155-885 Four Drive Expansion 

e Tape (CDC) 

- 4 679-7 Tape Transports 

(200 ips, 1600/6250 bpi) 

- 1 7021-31 Controller 

e Mass Storage System (MASSTOR) 

- 440 billion byte/s 

- 8 M861 Mass Storage Modules 
(16 read/write stations) 

- 2 M862 Dual Access Storage 
Controllers 

- 2 Channel Couplers (CDC 65206-X) 



625,000 


855,360 


176,340 


2,793,400 
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TABLE 4.2-5 (Concluded) 


COSTS OF A CDC SINGLE MAINFRAME 


ITEM 

© 10 Terminals 

- 10 Alphanumeric CRT's (CDC 722-10) 

- 4 Desktop Printers (CDC 755-20) 

- Installation Charges 

• Line Printer 

- 2000 1pm (CDC 580-20) 

- Printer Train Cartridge (GDC 596-6 

• 2 Conaaunication Subsystems 

- 2 CDC 2551-1 Network Processing 
Units (NPU) 

96K 16-bit words /NPU 

2 558-3 Couplers 

6 Sync. Comm Line Adapters (CLA) 
per NPU (2 Remote Lines/CLA) 

3 Async . CLA* s per NPU 
(2 Local CRT's/CLA) 

- Remote Site Interface 

22 Bi-sync Lines (11/NPU) 

9600 bps 

- CRT Terminal Interface (Hardwired) 
10 Asynchronous Lines 

9600 bps 


CDHF TOTAL GOST 


GDHF IMPLEMENTATION 

GSA PURCHASE PRICE ($) 
26,980 

95,078 

131,030 


8.236.388 
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4.3 Production Processing Demands/Estimates for PARS 

A summary of minimum production processing demands on the dual 
mainframe and single mainframe systems described in Section 4.1 and 
4.2 is presented in Table 4.3-1. It should be noted that these pro- 
cessing demands are minimal in that they do not include overhead re- 
sources such as those consumed by the operating system. 

Table 4.3-2 summarizes the minimal input, output and processing 
resources that would be consumed by ,'the IBM dual mainframe, CDC dual 
mainframe, and CDC single mainframe implementation. Again, as was 
noted for Table 4.3-1, tbe values listed in Table 4.3-2 are minimal 
since operating system resource demands and system inefficiencies are 
not included. 

4.4 QPEH/UARS CDHP Commonality 

Since the on-line storage required for OPEN is about 418 Gbytes 
(see Table 3.1-4), this is in the range of the mass storage systems 
envisioned for the PARS CDHF. Thus, major PARS system upgrades are 
only required to accommodate the higher OPEN processing load. The 
upgrade could be accomplished as follows; for the dual mainframe ap- 
proach, the Production Processor (PP) would be substantially upgraded; 
for the large single mainframe approach, array processors would be 
added. The latter approach appears to be the more straightforward and 
appears to offer the greater potential for achieving of hardware and 
software commonality. An explanation is given in the paragraphs that 
follow. 

Recall that for PARS, it is felt that a computer in the 10-11 
megainstructions/ sec range could accommodate all UARS processing, with 
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TABLE 4.3-l(a) 

MINIMUM PROCESSING DEMANDS ON IBM DUAL MAINFRAME 


CATEGORY 

DM/P 

(0,75 MIP) 


PP 

(3,0 MIP) 



IBM 

4341-L02 

% of 
8 hours 

IBM 

3033-N-8 

% of 
8 hours 

AP190L 

AP190L 

INGEST 

2133 sec 

7.4 





L-1 

8116 sec 

28.2 





L-2 



8580 

29.8 

11400 

11900 

L-3 

3963 sec 

13.8 





SECONDS 
TOTALS : 

HOURS 

14212 

49.3 

8580 

29.8 

11400 

11900 

3.948 

2.38 

3.16 

3.305 


Note : (Applicable to all of this table) 

[1] Mapping from raw data to L-0 assumes 8 instructions/L-0 
byte; does not include checksum processing. 
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TABLE 4.3-l(b) 

MINIMOM PROCESSING DEMANDS ON CDC DUAL MAINFRAME 


CATEGORY 

DM/P 

{1.2 MIP) 

— — — ^ — — 

PP 

(3.5 MIP) 


CDC 

170-720 

% of 
8 hours 

CDC 

170-730 

% of 
8 hours 

Advanced Flexible 
Processor 

INGEST 

1333 

4.6 


- 


L-1 

5073 

17.6 




L-2 



7354 

25.5 

2807 

L-3 

2477 

8.6 




SECONDS 
TOTALS ; 

HOURS 

8883 

30.8 

7354 

25.5 

2807 

2.468 

2.043 

0.779 


Note : 

[1] Mapping from raw data to L-0 assumes 8 instruct ions/L~0 
byte; does not include checksum processing. 

[2] Advanced Flexible Processor performs up to 200M arithmetic 
operations/ second; 1/8 rate assumed in these estimates; 
must be coded in assembly language. 


4-40 


















TABLE 4.3-l(c) 


MINIMUM PROCESSING DEMANDS ON IBM SINGLE MAINFRAME 


CATEGORY 

IBM 3081 
(10.4MIP) l3] 

% of 
8 Lours 

INGEST 

154 

0.5 

L-1 

585 

2.0 

L-2 

9223 

32.0 

L“3 

286 

1.0 

SECONDS 
TOTALS ; 

10248 

35.6 

HOURS 

2.847 



Note; 


[3J No external array processor. 
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TABLE 4.3-l(d) 


MINIMtJM PROCESSING DEMANDS ON CDC SINGLE MAINFRAME 


CATEGORY 

CDC 170-760 
(11 MIP) 

% of 
8 hours 

INGEST 

145 

0,5 

L-1 

553 

1.9 

L-2 

8720 

30.3 

L-3 

270 

0.9 

SECONDS 

9688 


TOTALS : 


33.6 

HOURS 

2,691 



Note ; 

[3J No external array processor. 
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TABLE 4.3-2 


MINIMUM PRODUCTIVE RESOURCE DEMANDS (HOURS) 


aiEGOllY 

IBM DUAL MAINFRAME 

CDC DUAL MAINFRAME 

IBM 

SINGLE 

MAINFRAME 

CDC 

SINGLE 

MAINFRAME 

DM/P 

PP 

DM/P 

PP 

INGEST: READ RAH 

0.79 

- 

0.79 

- 

0.79 

0.79 

PROCESS 

0.59 

- 

0.37 

- 

0.04 

0.04 

WRITE L-O 

0.56 

- 

0.56 

- 

0,56 

0.56 

L-1 PROC; READ L-0 

0.56 

- 

0.56 

- 

0.56 

0.56 

PROCESS 

2.25 

- 

1.41 

- 

0.16 

0,15 

WRITE L-1 

1.00 

- 

1.00 

- 

1.00 

1.00 

L-2 PROC: READ L-1 

- 

1.00 

- 

1.00 

1.00 

1.00 

PROCESS 

- 

2.38^^' 

- 

2.04^2^ 

2.56 ' 

^ 2.42 

WRITE L-2 

- 

0.37 

- 

0.37 

0.37 

0.37 

L-3 PROC: READ L-2 

0.37 

- 

0.37 

- 

0,37 

0.37 

PROCESS 

1.10 

- 

0.69 

r 

0.08 

0.08 

WRITE L-3 

0.13 

- 

0.13 

■- 

0.13 

0.13 

INPUT^^l 

1.72 

1.00 

1.72 

1.00 

2.72 

2.72 

TOTALS: PROCESS 

3.94 

2.38 

2.47 

2.04 

2.84 

2.69 

outputI^J 

1.69 

0.37 

1.69 

0.37 

2.06 

2.06 


Mote ; 

[1] In addition, concurrent array pcocesaing conaumee 3.16 hours of AP190L(1) 
rcsourcce and 3.31 hours of AP190L(2) reaourccs. 

[2] In addition, concurrent array proceasing eonaumes 0.78 hours of Advanced 
Flexible Processor (AFP) resources. 

[3] "Ingest; READ RAH" estimate based on 1.4619 x 10® bits input at 512K 
bits/sec; all other "READ/WRITE" estimates use an estimate of 10 usee per 
byte. 
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no attached array processor required, in about 3 hours (theoretical 
throughput). Since the OPEN processing load is estimated to be about 
5.2 times that of UARS (Section 3.2.2), it would appear that about 
15.6 hours of the UARS mainframe would be required for OPEN. However, 
five of the OPEN instruments are estimated to consume 90% of the OPEN 
processing load (also Section 3.2.2), and these instruments’ data are 
suitable for efficient array processing. Hence, the attachment of 
array processors to the UARS single mainframe offers promise for sig- 
nificantly reducing the 15.2 hour demand on the computer. If this is 
the case, without substantial hardware design, commonality could be 
achieved. 

In addition to the common hardware design inherent in this ap- 
proach, there could be promise for achieving a measure of software 
commonality. As seen in Section 5, there .appear to be substantial 
areas of commonality between the OPEN and UARS software systems both 
in the areas of data management software and the production software. 
If both OPEN and UARS processing utilized the same mainframe, then the 
software would be available to both and substantial cost savings could 
be realized. 
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5.0 CDHF DATA. PROCESSING AND MANAGEMENT CONCEPT 


5.1 Introduction 

Given ^that a TIARS or an OPEN CDHF can be configured from readily 
available "commercial hardware subsystems such as those presented in 
Section 4, this section will point out several challenges which re- 
quire in depth exploration in order to provide remote users with rapid 
and reliable access to the massive volumes of EARS and OPEN data which 
will be stored on~line at the respective CDHF's. The quantity of on- 
line data at the UARS CDHF will be in the neighborhood of 200 giga- 
bytes, OPEN CDHF on-line data requirements, being in excess of 400 
gigabytes, are more than double those of UARS. 

UARS investigators have submitted preliminary lists of retrieval 
keys and browsing criteria, as listed in Tables 5.0-1, 5.0-2, and 5.0- 
3. OPEN investigators are expected to submit similar requirements in 
the future. An implication of the lists of retrieval keys and browsing 
criteria listed in Tables 5,0-1, 5.0-2, and 5.0-3 is that use of a 
data base management system (DBMS) and query language might be employ- 
ed at the respective CDHF's to facilitate the remote user interface 
with the on-line data. However, the decision to employ a DBMS, such 
as today's commercially available products, must be carefully inves- 
tigated. In particular, the topics of access speed, data base recovery 
and data base reorganization must be considered. 

Adequate data access speeds in a DBMS environment involving data 
bases of several hundreds of gigabytes could require that extensive 
additional high speed disk facilities be added to the hardware con- 
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figurations presented in Section 4. This could significantly increase 
the costs of the configurations presented in Section 4 since all of 
the configurations rely on relatively inexpensive IBM or MA.SSTOE. mass 
storage facilities (MSF's) to minimize the costs of on-line data 
storage. MSF costs are approximately $70,000 for each 10 gigabytes of 
storage, while a corresponding amount of high speed disk storage would 
cost in excess of $1,5 million. Both the IBM and MASSTOR devices 
store data on randomly accessible magnetic tape strips. Access times 
for these devices are approximately five to ten seconds per tape strip 
and can be even longer when all available read/ write stations are in 
use. The ability to configure these devices into a DBMS system is 
essential if CDHF storage costs are to be kept at a minimum. 

Any DBMS considered for use at the CDHF must possess features 
which minimize the amount of the data that must be restored following 
data-destructive hardware or software malfunctions. Halfway through 
the lifetime of the UARS CDHF complete restoration of the on-line data 
from backup tapes would involve reading several thousand reels of tape 
over a period of several hundreds of hours. The data base restoration 
capabilities of any DBMS considered for the UARS or OPEN CDHF must he 
among the prime considerations. 

✓ 

Any DBMS system considered for use at the UARS or OPEN CDHF must 
possess features which will minimize the time and effort required to 
reorganize the data base in order to overcome unacceptable access 
speed deterioration or potential storage saturation. Once significant 
amounts of data have been collected reorganization of the data base 
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would become impractical if it involved the re-entry of extensive 
amounts of data from several thousand reels of tape. 

The remaining paragraphs of this section present a unified data 
processing and management concept which would simplify the data resto- 
ration process and eliminate the possibility of having to reorganize 
massive data bases. 

5.2 Data Processing and Management Concent 

A description of a common approach to ITASS and OPEN data manage- 
ment is provided in the following paragraphs and summarized pictorial- 
ly in Figure 5.2-1. The concept presented would make use of standard 
system sequential file processors (vendor utilities) to manage the 
large quantities of UARS or OPEN data at the CDHF and would thus 
minimize storage overhead for these data, . Use of sequential files 
would also simplify any data restoration process required to recover 
data destroyed as the result of system malfunctions. Since large 
sequential files do not lend themselves to rapid querying by remote 
users, a Data Locator Data Base (DLDB) designed for fast access would 
be provided to assist users in locating data of interest. The DLDB 
would be event and condition oriented and would be of a coarser time 
granularity than the UARS and OPEN data that is summarized. Such a 
data base, being a summary of the data elements used to derive it, 
could be much mote compact and rapidly accessible than would be a data 
base which consisted of the constituent data elements of the events 
themselves. Vectors into specific files that contained data 
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corresponding to particular events or conditions would be filed in the 
DLDB to provide the user with the information necessary to access, 
browse through or retrieve data of interest. 

5.2.1. Production Cycle 

Similarities between UARS and OPEH suggest that a common software 
production framework and collection of production software utilities 
could be configured for use at both -CDHF’s. 

As pictured in Figure 5.2-1, a typical production cycle would 
begin with the arrival of spacecraft data via the data capture faci- 
lity. Raw data would be read into the CDHF data processing system by 
the Data Ingest Processor, subjected to elementary quality control 
checks, and stored. Subsequently the Production Processors (PP) would 
be activated in turn. These production processors need not be unique 
to a particular CDHF. During the production processing the various 
PP's would input raw or L-(n) data and any required spacecraft or 
instrument oriented support data and produce a specific L-(n+l) out- 
put. As various segments of the production process are completed, 
appropriate Data Scan Processors (DSCAK) would be activated. The 
function of the DSGAN processors would be to examine the various new 
production files registered in the system Master File Directory (MFD) 
and to develop (predefined) summary information for incorporation into 
the Data Locator Data Base (DLDB). As an example, the DSGAN might 
note at which point in time a peak reading occurred in a particular 
subsystem and record such items as (1) the value of the reading, (2) 


5-8 



the (real) time and date at which the event occurred, (3) instrument 
status, (4) the name of the data file containing the reading, and (5) 
the relative position (within the data file) of the readingo Sub- 
sequently the DSCAH would submit this (and other) significant events 
data to the Data Base Management System Processor (DBMS?) for incor- 
poration into the DLDB. Once incorporated into the DLDB, the signifi- 
cant events and vectors into the production data file system would be 
available to the user community via the Interactive Query Processor 
(IQP). 

5.2.2 User Interface 

The concept presented in Figure 5.2-1 provides four processors to 
allow users to submit, locate and retrieve data. These processors are 
as follows: 

• Data Submission Processor (DSUB) 

• Interactive Query Processor (IQP) 

• Interactive Browse Processor (IBP) 

e Data Retrieval Processor (DRP) 

Table 5.2-1 illustrates how these and other CDHF processors could be 
used to conduct activities analogous to those carried out at a conven- 
tional library of printed books. 

5. 2. 2.1 Data Submission Processor 

The DSUB processor would permit users to submit a variety of data 
into the CDHF data system. Three major types of data (correlative, 
support and L-H data) are noted in Figure 5.2-1. Incoming correlative 


5-9 




TABLE 5.2-1 


CDEF VERSUS CONVENTIONAL LIBRARY FUNCTIONS 


Function Conventional Library CDHF 

Data Generation Book purchases. Production Programs generate 

L-0, L-1, L-2 and L-3 data. 
Remote users submit higher 
level L-H data (>L-3) and 
correlative data using the 
Data Submission Processor. 


Data Scan Processor examine 
new or changed L-0, L-1, 
L-2, L-3 and L-H data and 
generate updates for the 
Data Locator Data Base. 
Correlative data are used 
to update the Data Locator 
Data Base. 


User examines index User accesses Data Locator 
card files and notes Data Base using the Inter- 
volume numbers and active Query Processor and 

pages of interest. is presented with lists of 

files and locations within 
files wherein might reside 
subject matter of interest. 

Text Search User requests vol- User accesses potential 

umes of interest and areas of interest within 
browses pages of data files using the Inter- 

interest; specific active Browse Processor; 
data of interest are user determines data of 
determined. interest. 

Volume/Text/Data User checks out vol- User instructs Data Retrie- 

Acquisition ume of interest or val Processor to transmit 

copies pages of in- copies of data sets or sub- 

terest. sets to user's remote faci- 

lity. 


Subject Matter 
Search 


Indexing Index card files are 

updated with indica- 
tions of new volumes 
and subject matter. 
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data, such as measurements from ground observations or sounding 
rockets, would be forwarded to the DBMS processor for incorporation 
into the DLDB. Support data, such as instrument calibration data, 
would be vectored into Support Data ^iles (SDF) where they would 
become available to the various PP' s. Incoming L~H data (levels of 
processing greater than standard production data) developed at remote 
user facilities would be vectored into L-H Files (L-HF). Newly re- 
ceived or updated L-EF data would be scanned by appropriate DSCAN 
processors for significant events and the DLDB would be updated (using 
the DBMS processor) in a manner similar to that used with the produc- 
tion files. 


5. 2, 2. 2 Interactive Query Processor 

The IQP, operating in conjunction with the DLDB, would be a key 
user/system interface. Pi's have already indicated how they will 
desire to locate data residing at the CDHF; Tables 5.0-1, 5.0-2 and 
5.0-3 summarize the data attributes which EARS investigators identi- 
fied as being of interest. In the concept presented in Figure 5.2-1 
the data attributes listed in Tables 5.0-1, 5.0-2 and 5,0-3 (along 
with others to be defined) would be used to formulate queries which 
would be submitted to the IQP. Various attributes, such as those 
listed in the tables, would be linked together logically with delimit- 
ing values to form queries describing the data of potential interest. 
Figure 5,2-2 illustrates how such a query might appear. The data 
presented as the response in Figure 5.2-2 would have been previously 
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QUERY: 


RESPONSE: 


LOCATE DATA FOR SUBSYSTEM name : 

CRITERIA ARE: 

ORBIT~NUMBER = m or n 
AND DATA-QUALITY is xxxx 
AND IRRADIANCE-INDEX > yyy; 

LIST DATA-SET-NAME . DATA-LOCATOR-NUMBER . 


DATA-SET-NAME DATA-LOCATOR-NUMBER 

namel 115-120 

135-166 

168 

name2 350 

355-360 

363 


FIGURE 5,2-2. SAMPLE QUERY AND RESPONSE 
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entered into the DLDB by the DSCAN processors previously discussed. 
The data set names and data set numbers could subsequently (by either 
automatic or manual interfaces) be used as inputs to drive the Inter- 
active Browse Processor and the Data Retrieval Processor. 

5. 2. 2. 3 Interactive Browse Processor 

The purpose of the IBP would be to permit remote users to visual- 
ly examine selected data fields within a particular production or L-H 
file. Use of the IBP would usually be preceded by use of the IQP to 
determine the general location(s) of data of interest. Once the 
general location(s) of the data of interest had been determined the 
user would instruct the IBP to position the data file of interest to 
the general area of interest. Subsequently, the user would command 
the IBP to position the file forward and/or backward and to display 
specific data fields of interest as illustrated in Figure 5.2-3. 

5. 2. 2. 4 Data Retrieval Processor 

Remote users would use this processor to designate sets or sub- 
sets of production or L-H data for which copies are desired. The Data 
Retrieval Processor (DRP), in turn, would locate the specific data and 
transmit a copy of that data to the remote user. Use of the DRP would 
frequently be the final activity in a QUERY-BROWSE-RETRIEVE sequence 
of activity. 

5.2.3 Data Security 

Since the data stored at the CDHF will represent significant 
expenditures of manpower, analytic and data processing resources, it 
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COMMANDS ; 


OPEN filename 


RESPONSE: 


COMMANDS : 


RESPONSE: 


ADVANCE TO DATA- LOCATOR-NUMBER 
DISPLAY namel ^ nameZ , name3 ^ GMT 


namel = datal 
name2 = data2 
names = data3 
GMT = time 


ADVANCE UNTIL GMT = timel 
DISPLAY name2 , GMT 

name2 » data2 
GMT “ timel 


FIGURE 5«2-3. BROWSE SEQUENCE 
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is essential that the CDHF include the necessary elements of security 
to protect data from accidential or deliberate loss or destruction. 
The concept presented in Figure 5.2-1 would include provisions for 
data security that would minimize the chances for the loss or destrucr 
tion of data by providing off-line backup copies of data and by con- 
trolling accesses to on-line data. 

5. 2. 3.1 Off- Line-Backup 

In the concept presented in Figure 5.2—1 the creation of off-line 
backup copies of on-line data would be provided using File/Data Backup 
Processors (F/DBP). While processors could be. especially written for 
the CDHF, in many cases off-the-shelf system utilities are available 
to provide backup file copies on magnetic tape. 

The creation of off-line backup data copies (probably using mag- 
netic tape as a backup medium) would be an ongoing process throughout 
the lifetime of the CDHF, F/DBP* s, working in conjunction with an 
overall System File Management Processor (SFMP) could insure that 
backup copies of all newly established or modified on-line data would 
be created on a regular basis. In the event of system software or 
hardware failures or user errors resulting in the loss of on-line 
data, an appropriate F/DBP could re-establish the data on-line from 
the most recent backup copy available for that data. Such a recovery 
method would avoid the necessity of lengthly (multi-hour, in some 
cases) computer runs to recreate lost data from lower level data. 
Figure 5.2-1 illustrates a flow of data between on-line storage and 
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Local off-line storage. While the local off-line storage facility 
would be a functional element of the GDEF, the physical location of 
the storage facility itself might be somewhat removed from the CDHF 
computing facility in order to preclude the loss of both on-line and 
off-line copies of data ^n the event of a catastrophic event such as a 
fire in the CDHF, 


5. 2. 3. 2 Data Access Controls 

Since the CDHF system will be a multi-user system, access to on- 
line data will of necessity be limited to a certain degree (at a mini- 
mum it would be necessary to prohibit concurrent updating of the same 
data by multiple users and/or processors). An indication of the types 
of user access control that will be required is as follows: 

• Any user or appropriate processor may gain read access to any 
data which is not being written, modified or deleted by 
another user or processor. 

« Production data may be created, modified or deleted only by 
the Production Processors, the File/Data Back Processors or 
the CDHF staff. 

• Any user may submit new correlative data, support data or L-H 
data, subject to predefined authorization restrictions. 

« Any user may augment, modify or delete only the data that he 
has created and, further, only when such activities would not 
conflict with the access of another user or processor. 

In terms of Figure 5.2-1, these types of access control could be pro- 
vided by the SFMP and the DBMS processor. User identification codes 
or account numbers augmented (if necessary) by "add/modify/delete" 
privilege passwords would probably prove adequate. 
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5.2.4 Archive Function 


Details regarding the extensive quantities of data that must be 
archived will be presented in Section 6. Depending upon the nature 
and compatibility of the archive medium and/or interface, the Archive 
Processor included in Figure 5.2-1 would prepare (1) archive data 
using the actual archive medium and format or (2) intermediate copies 
of archive data, using a medium sueh,>as a computer compatible tape, 
for subsequent transcription onto the archive medium. While archive 
medium generation for production and higher level data could be 
postponed until the end of the CDHF lifetime, consideration should be 
given to an ongoing archive process (perhaps a daily or weekly archive 
generation run) throughout the CDHF lifetime. An ongoing .archive 
process (of data which have become static) could preclude the 
necessity for an extended series of archive production runs involving 
the transfer of hundreds of billions of bytes of data from on-line 

storage. The introduction of the concept of an ongoing archive 
process might also lead to significant savings in time and resources 

if it proved feasible to combine certain elements of the archive 
process and the ongoing data backup process described in Section 

5. 2. 3.1. 
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6.0 DATA ARCHIVES 



6.0 DATA ARCHIVES 


The analysis presented in this section describes archive require- 
ments for the CDHF data. Although the details are derived for TJARS 
data, the UARS numbers can be scaled up to the OPEN numbers keeping in 
mind the following: Daily OPEN data volume exceeds UARS data volume by 
about 50%; and total OPEN mission data exceeds total UARS mission data 
by a factor of about 7 (see Tables 6.1-1 and 3.1-4, respectively). 

6 cl Data Volume 

For UARS, the five types of data discussed in this analysis fall 

r 

into two general categories: 

• Standard data products (L-0, L-1, L-2, L-3) 

• Non-standard data products (L-H); i.e., higher order data 
(>L“3) submitted from remote sites. 

Table 6.1-i lists the estimated volume for each level of UARS data. 
The standard data products are those produced on a daily basis at the 
CDHF, Standard data products will be produced at a known rate and the 
size of each product will be known. The production rates and sizes of 
the non-standard data products, in contrast, will vary as a function 
of UARS PI findings and activity. Note that other data at the CDHF 
such as software, support data (calibration processing coefficients, 
ground truth measurements, other correlative measurements), ephemeris 
data, etc., are not considered in this analysis of archive require- 
ments. 

It should be noted that the ’'Megabyte” estimates given for vari- 
ous types of data refer to the space that would be occupied by binary 
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TABLE 6.1-1. UARS ESTIMATED DATA VOLUMES (Megabytes) 


Data 

Tyne 

Daily 

Volume 

Total 
(540 Days) 

L-0 

199.95 

107,973 

L-1 

356,70 

192,618 

L-2 

133.33 

71,998 

L-3 

48.35 

26,109 

L-H 

16.79 

9,067 

Total 

755.12 MB 

407,765 


Note; Data volumes in terms of space required, to store binary images 
of integer, single precision floating point and double preci- 
sion floating point values. 
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images of integer values, single precision floating point values and 
double precision floating point values; the estimates do not refer to 
data stored in character format. Conversion of binary data to numeric 
character strings, as illustrated in Figure 6,1-1, could easily 
double, triple or quadruple the size of the UARS data archives. 

Table 6.1-2 indicates daily and 540 day (total) UARS archive data 
in terms of binary data stored on 9 track 6250 bpi computer compatible 
tape (CCT) reels. The information in Table 6.1-2 is based upon the 
tape capacity data listed in Table 6.1—3. The first part of Table 
6.1-2 assumes a daily archive production run in which all archive data 
are copied to tape sequentially, leaving only the last tape of a daily 
composite archive set partially filled. If, however, a separate set 
of archive tapes is produced for each of the five levels of- data on a 
daily basis, the daily volume of archive tapes would increase from the 
range of 5-7 reels to the range of 8-10 reels as shown in the second 
part of Table 6.1-2. Likewise, total archive storage would increase 
from the range of 4500-6300 reels to the range of 7200-9000 reels. 

6 ,2 Further Considerations 

If CCT in the binary format is chosen as the UARS data archive 
medium, the quantity of 6250 bpi tape reels that will be generated 
will be in the range of 4500 to 9000 reels of tape. 

Binary image format offers a distinct advantage because of its 
compactness. However, a distinct disadvantage of storing binary data 
is that such data will have to undergo extensive pre-processing when 
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Byte 1 


Byte 2 


Byte 3 


Byte 4 


00000000 00001111 01000010 01000000 

I I I I ■■ I ■ I 

(a) +1000000^0 stored as 32 bit binary signed integer 

Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8 

00101011 00110001 00110000 00110000 00110000 00110000 00110000 00110000 
+ i 0 6 0 0 0 0 

+1000000j^Q stored as an ASCII character string 
FIGURE 6.1-1. AN ILLUSTRATION FOR STORING BINARY VERSUS CHARACTERS 
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TABLE 6.1-2. UARS 6250 BPI ARCHIVE TAPE VOLUME 


O 9 

-n -X 

"0 ® 

o ^ 

O •p‘ 

?o F 

cl S: 

O' 


a- 




COMPOSITE 

SETS 


SEPARATE SETS 

Data Type 

Daily 

Volume 

(Megabytes) 

Number 

Using 

4096 

of 6250 bpi Archive Tapes When 
Record Lengths of (in bytes); 

8192 16384 32768 65536 

Number 

Using 

4096 

of 6250 bpi. Archive Tapes When 
Record Lengths of (in bytes): 

8192 16384 32768 65536 

L-0 

199.95 

1.70 

1.42 

1.29 

1.23 

1.19 

2 

2 

2 

2 

2 

L-1 

356.70 

3.03 

2.54 

2.30 

2.19 

2.13 

4 

3 

3 

3 

3 

L-2 

133.33 

1.13 

0.95 

0.86 

0.82 

0.80 

2 

1 

1 

1 

1 

L-3 

48.35 

0.41 

0.34 

0.31 

0,30 

0.29 

1 

1 

1 

1 

1 

L-H 

16.79 

0.14 

0.12 

0.11 

0.10 

0.10 

1 

1 

1 

1 

1 

Total 

755.12 

6.41 

5.38 

4.88 

4.63 

4.51 






Whole Reels 
Per Day 

7 

6 

5 

5 

5 

10 

8 

8 

8 

8 

Whole Reels 
For 540 Days 

3780 

3240 

2700 

2700 

2700 

5400 

43 20 

4320 

4320 

4320 



TABLE 6.1-3. CCT CAPACITY AT 6250 BITS/ INCH 


Data Record Data Record' Records Per Megabytes Per 

Size (Bytes) Length C Inches ) ^ ^ ^ 2400 Ft Reel^^^ 2400 Pt Reel^^^ 


4096 

0.96 

28750 

117.760 

8192 

1.61 

17142 

140.427 

16384 

2.92 

9452. 

154.862 

32768 

5.54 

4981 

163.217 

6 5536 

10.79 

2557 

167,576 

Notes : 

[11 

Includes 0.3 inch 

inter-record gap. 



[2] 2,300 ft. useable recording length 

(50 ft. leader, 50 ft. trailer) 
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used on computing systems whose arithmetic structure differs from that 
of the CDHF processing equipment. 

There is little doubt that the most desirable format for archived 
data would use a universally recognized format such as ASCII character 
strings. However, as noted earlier, the already large quantity of 
reels of tape required to archive UARS data could increase to several 
tens of thousands of reels of CGIs if data are archived in the charac- 
ter format. 

Further investigation of the question of the UARS archive medium 
and format will be essential to establish an archive which is user 
accessible, compatible with potential users* computing machinery and, 
at the same time, reasonable in its physical size. 

An alternate solution to the archival storage medium is the use 
of optical disks. This technology is however still in its infancy and 
at the present time has a major weakness ~ error rates, which are much 
higher than magnetic tape. But because its advantages of more storage 
capacity in less space, faster access time and larger archival life 
are so promising, the implementation of optical disk systems for digi- 
tal applications is a subject of considerable commercial and govern- 
ment research. 
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7.0 COMHimiCATIONS COSTS: CDHF/R.EMOTES 

In order to derive cost estimates for CDHF/Remote communications 
a comparison was made for the following three modes: 

• Packets 

• Digital Service Leased Line 

• Satellite Hop 

The comparison was made under the -following assumptions: 

• Remote located 2000 miles from GSFC 

• 12 Mbytes/day of traffic (average) between GSFC and a UASS 
Remote 

• 38.5 Mbytes/day of traffic (average) between GSFC and an OPEN 
Remote. 

The 12 Mbytes/day average between the UARS CDHF and a Remote is de- 
rived as follows: Total traffic from the UARS CDHF to the Pis per day 

is (see Table 3.1-1): 

All of L3 (Further analysis ) = 48.35 

10% of LO (Quicklook) = 20.00 

5% of LI (Dev. verif ./anal.) = 17.84 

20% of L2 (Dev. verif ./anal.) = 26.67 

112.86 MB 

Additionally, the amount of data products transmitted from the Pis to 
the CDHF for the use of other investigators is assumed to be equiva- 
lent in volume to: 

10% of L3 (Other users) = 4,82 MB. 

Thus, this total two-way traffic is about: 

112.86 + 4.83 = 117.69 MB/day, 
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since there are ten instruments, the average amount of data associated 
with each instrument and hence the average two-way traffic per TJARS 
Remote is: 

117.69 / 10 = 12 WB/day. 

The 12 MB/day derived here is just an average; traffic between the 
CDHF and a specific Remote can be more accurately estimated by using 
Table 3.1-1. 

The 38.5 MB/day traffic between the OPEN CDHF and a Remote is 
similarly derived: In this case the sum of the following data volumes 

is taken: 

All of L2 (Further analysis) 

10% of LO (Quicklook) 

10% of LI (Dev. .verif, /anal. ) 

Data equivalent in voltime to 10% of L2 (Remote to CDHF 
for other users) 

Using Table 3,2-1, this sum is equal to 1233 MB, Dividing by 32 in- 
struments yields the number 38.5 MB. 

Table 7.0-1 presents a summary of the communications costs to the 
Remotes, The cost figures for Packets and Digital Service Leased Line 
were derived from Fundamentals of Data Communications by Jerry Fitz- 
gerald and Tom. S. Eason, 1978. The satellite communications costs 
were based on Planning Research Corporation (PRC) System Services 
Company’s NASCOM Circuit Regression, which appears in Development of 
NASA DMS Perf ormance/Cost Models, dated 5 January 1982, The details 
for the cost derivations are given in the paragraphs below. 
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TABLE 7.0-1 


COMMUNICATIONS COSTS (DOLLARS /MONTH/ REMOTE) 


Commimicatiou Mode 

Costs (Dollars/Moath/Remote) 


UARS 

OPEN 

Packets 

$18,768 

$59,274 

Leased Line 

$2,139 

$2,139 

Satellite (Domestic) 

$3,370 

$3,370 

Satellite (Overseas) 

$19,430 

$19,430 
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7 ol Domestic 


7tl.l Packets 

In addition to an installation fee of about $1,000, there are 
three cost factors : 

e Packet Transmission Cost = $0.60/1000 packets 

$0.60/128,000 characters (bytes) 

• Network Access Arrangement = $200/hour 

® Network Interface Equipment = '$40 0/month. 

Note that packet transmission costs are independent of distance. 

In the case of UARS, since a transmission of 12 MB requires about 
2.78 hours on a 9.6 Kbps line, the monthly cost, would be: 

$200 X 2.78 hr x 30 day + $400 + $0.60 x 

hr ' day month month 128,000 bytes 

12,000,000 bytes x 30 days = $18,768/month/UARS Remote 
An additional overhead cost must be added for packet header informa- 
tion. 

For the OPEN case, since a transmission of 38.5 MB requires about 
8,91 hours on a 9.6 Kbps line, the monthly cost would be: 

$200 x 8.91 hr X 30 dav + $400 + $0.60 x 

hr day month month 128,000 bytes 

38,500,000 bytes x 30 days = $59,274/month/OPEN Remote 

7.1.2 Digital Service Leased Line 

In addition to an installation fee of no more than $1,000 there 
are three cost factors: 

e Intercity Line Mileage = $62/month + $0. 93/mile (assuming' 

2000 miles) 
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• Service Terminals = $134/month + $l,34/mile (asstmiing 

50 miles from end office) 

« Network Interface Equipment = $1 6/mon tk 

The total monthly cost would be: 

$62 + $0.93 X 2000 + $134 + $1.34 x 50 + $16 = $2,139/month/Reinote, 

either TJARS or OPEN 

Note that since this service would be provided on a 24 hours/day 
basis, considerably more than the assumed data volumes could be trans- 
mitted at the same cost, 

7.1.3 Satellite Communications 

The formula for computing the annual communications cost for a 
domestic satellite circuit is given by: 

FY 1982 K Dollars = ( 11 . 98 ) [(kilometers)(Megabits)]0*3508 

with an error of +7%. 

Since 2,000 miles is about 3200 kilometers and 9,600 bits is 

about 0.01 megabits, the annual cost in kilodollars is: 

FY 1982 K Dollars = ( 11 . 98 ) [ (3,200)(0.01)]0.3508 

= 40.41 

The monthly recurring cost would thus be: 

$40,410 / 12 = $3,370/month/Remote,. either OARS or OPEN. 

7.2 Overseas Circuits 

The formula for computing the annual communications cost for an 
overseas satellite circuit is given by: 

FY 1982 K Dollars = (700.6) (Megabits)O .2389 
■ with an error of +,16%. 
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Since 9,600 bits is about 0.01 megabits, the annual cost in kilo- 
doliars is: 

FY 1982 K Dollars »= ( 700 . 6 ) (0.01)0*2389 

= 233.17 

The monthly recurring costs would thus be; 

$233,170 / 12 = $19,430/month/Remote, either OARS or OPEN, 
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8.0 POTENTIAL TECHNOLOGY APPLICATIONS 


The technology for implementing the UARS and OPEN data systems exists 
at the present time. However, there are technologies that should be 
available during the mission time-frames that could be utilized for a more 
cost effective or better performing system. The technologies examined are 
in the areas of data management, mass storage, software language 
development and communications . 

8.1 Data Management 

The most promising potentially applicable data management technology 
is that of the data base machine. Until recently data base management 
systems (DBNS''s) have been software systems which executed on standard 
general purpose computers. However, two major' iimitations have surfaced 
under this implementation scheme. Data management systems that run on 
conventional computers run into bottlenecks when processing a large volume 
of transactions on very large (10 Gbytes) data bases. This is due to the 
data staging "bottleneck" between mass storage and main memory. The second 
limitation is that users are continually demanding more sophisticated DBMS 
capabilities such as backup and recovery, integrity and security controls, 
etc. These capabilities are needed by OPEN and UARS and require tremendous 
overhead. Consequently, a number of researchers have proposed the use of 
dedicated or specialized processors to 'execute data management functions. 
These are called data base machines (DM). 

Several DM architectures are under investigation. All involve 
parallelism in one form or another and therefore take advantage of emerging 
VLSI technology. An example of a DM available today is a Britton-Lee 
computer designed specifically for DBMS processing. With software and 
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hardware the entire system can be purchased for about $200,000 (cost will 
vary depending on data base size and options). It is capable of data base 
access times equivalent to those obtained on a 5 to 10 MIPS standard 
computer with a software data base and there are plans to increase 
performance by another 5 to 10 fold. It will currently support up to 10 
Gbytes of disk storage. 

8.2 Mass Storage of Data 

A common theme to the OPEN and OARS architectures discussed in this 
volume is that to achieve a balance between operational performance and 
system costs a hierarchy of computer memories/storage technologies is 
required. This hierarchy consists of a spectrxm of cache/main memory, mass 
storage, and archival memory devices that span roughly six orders of 
magintude in both performance and cost. Because most technology involved 
in the existing memory hierarchy continues to reduce the per-bit storage 
cost at about the same rate, there will be no cross-over within the 
hierarchy within the near future. Therefore, memory hierarchies will 
continue to play a key role in the design of cost effective system 
architectures . 

The storage technologies for accomplishing the objectives of the OPEN 
and UARS missions are well at hand. However, although there are numerous 
choices which can be made among alternate computer systems for performing 
production and communication tasks, there are only two choices for 
implementing the mass storage function. These choices, describe previously 
in this report are the IBM Mass Storage System (MSS) and the Masstor 
Virtual Storage System (VSS). Both these systems are basically automated 
magnetic tape-cartridge read/write systems that access the appropriate 
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cartridge, load it, and transfer the data to a staging disk in a matter of 
seconds. In the near term it does not appear that these devices will be 
supplanted. However, it can be anticipated that with the continuing price 
decrease in VLSI technology, more device intelligence will be built into 
mass storage devices. This would help remove the data-location burden from 
the CPU as well as minimize I/O traffic between mass storage and main 
memory. Additionally there could be an implementation in the mass-storage 
devices of such features as format initialization, limit checking, data 
compression and expansion, and error correction. 

On the horizon the only apparent alternative to the magnecic cartridge 
mass storage devices seems to be the emerging optical disk storage systems. 
Optical disks promise a higher storage density and a lower per-bit cost 
than any other mass storage medium. Additionally they are they are made of 
materials that can be stored for many years without stringent environmental 
controls. However, opitcal disks suffer the drawback of being write-once 
devices. Although most magnetic tape is used in a write-once manner, 
there is a reluctance to utilize a new technology that forces this mode of 
operations . 

At the present time, RCA has completed experimental optical disk 
systems that can record 5 Gbytes of data on one side of an optical disk at 
rates exceeding 100 Hbits/sec. These systems have provided a bit error 
rate of one-in-100 Mbits and can access any block of data in less than 0.5 
seconds. There are plans to design a unit that would hold a number of 
optical disk platters that would be retireved and loaded as the need arose. 
It is planned that the worst case access time for a data block in this 
system would be about 5 seconds to retrieve data from a stored disk and .5 
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seconds if the disk were already on line. This type of system has been 
proposed to have 1.25 terabytes of storage. 

Before optical data storage hardware becomes a reality, however, much 
work remains in the mechanics, the optics and the recording medium. 
Nonetheless, the current level of development activities suggests that 

k 

0 

operational systems will become widespread by the late 1980's or early 
1990's. 

A mass storage system that is exclusively optical disk does not appear 
feasible for OPEN and UAES— type projects because the write-once limitation 
could lead to a database size of over a terabyte. However, reversible data 
(Levels 0 and 1 for UARS and Level 0 for OPEN), which would rarely be 
altered, could be optically stored. An example of an advantage here could 
be the ease by which large quantities of this data could be recorded on a 
single disk (5 Gbytes or more) and sent by an express package service to 
the investigators. This could relieve a heavy I/O and communications 
burden from the CDHF. 

8.3 Software Language Developments 

The most likely major transition in languages that can be expected 
in the near future is the acceptance and use of the Ada language. Ada is 
currently under development by the Department of Defense (DOD) to be used 
in all of their software systems. Not only is it a powerful and flexible 
structured language, but it also serves as a program support environment, 
particularly for transportability, as well as supplying a methodology for 
life cycle software development, particularly in the area of configuration 
management. The use of Ada for OPEN and UARS would require massive 
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programmer retraining, the positive features of Ada may not outweigh this 
initial disadvantage. Moreover the cost benefit of Ada has not yet been 
proved . 

Currently there are research efforts under way for producing compilers 
for automatic program generation in the sense that languages would be 
produced which would allow statements about what the program is^to do to 
generate high-level language algorithms for stating how the program is to 
produce the desired results. For languages under current research, the 

M* 

compiler determines the sequence of procedures by analyzing the statements 
entered. This is in contrast to conventional languages in which control 
flow is built into the program itself. 

At the present time there are no commercially available compilers for 
automatic program generation. It does not appear that one would be 
available for OPEN and TJARS. Moreover, it remains to be seen whether 
increased hardware performance can overcome the potential slowness and 
inefficiency of multi-level compilers which first translate specifications 
into high-level languages and then into machine-language Instructions . 

8.4 Communications 

Communications will be paced by advances in satellites and optical 
fibers. 

In satellite communications, research in the areas of space diversity 
and time-division techniques, developments in antenna technology, 
sophisticated high-speed on-board switching, exploiting higher frequency 
sections of the spectr\m, and on-board error detection and correction would 
provide for much broader wideband capabilities in space. However, under 
the communications traffic assumed by UARS, for example, recurring 
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satellite and terresterial communications costs were about the same. As 
long as rate structures are determined as a function of distance, this can 
be expected to remain the case. It remains to be seen if this policy will 
change. 

Over the next few years local networks will be wire-based. If fiber 
is to compete, interfaces must be developed for fiber-optic systems that 
are compatible with coaxial networks such as Ethernet. Also, research is 
needed to define network topologies.,, that best utilize fiber optics. 
Standards are now being established for defining a general class of 
terminal device for an optical fiber system. A goal would be the 
interchangability of the terminal device with a terminal device for a wire- 
based network. 

Outside of local network applications, high-speed fiber optic buses 
may fill the need for fast parallel transfers between a mainframe and high- 
speed peripherals. This may serve to relieve any potential data staging 
bottlenecks between mass storage and main memory, as could be the case in 
the CDHF. 
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APPENDIX* A' 

OPEN AND DARS MISSIONS 
ASSUMPTIONS AND' INTERCOMPARISONS 



UARS 


Spacecrafts 


1 Satellite 


Orbit 


56° Inclination 
600 Km Orbit 


Lifetime (months) 


18 


OR!Q1^3AL PAGE Si 
OF POOR QUALITY- 


SEGMENT 


OPEN 


i4 Labs* 

- IPL (Interplanetary Physics Lab) 

- PPL (Polar Plasma Lab) 

- GTL (Geomagnetic Tail Lab) 

~ EML (Equatorial Magnetosphere Lab) 

* Contingency plan for a fifth lab 
(as spare) 


Min. Slant Max, Slant 

Range Range 


IPL 

Halo: 

250 Rg 

Halo; 250 Rg 

PPL 

Initial : 
Final ; 

300 to 
3000 Km 
300 to 
3000 Km 

Initial: 5 

Final: 15 

^E 

^E 

GTL 

60 Re 


250 Re 


EML 

2 Re 


12 Rg 


All labs have on-board propulsion 
systems to effect major alterations 
to orbital configurations 

IPL 

GTL 

EML 

PPL 


36 

36 

30 

24 



- Simultaneous operations of 4 labs for 
2 years (6 months min.) 














FLIGHT SEGMENT (Concluded) 



UARS 

OPEN 

Retrievable 

Possibly 

NO 

Launch 

STS 

STS 


October 1988 

IPL: February 1989 
PPL: February 1990 
GTL : February 1989 
EML: August 1989 

Launch-Site 

ETR 

IPL: ETR 

PPL ; WTR 
GTL: ETR 

EML ; ETR 

On-Board Tape Recorders 

YES 

YES 

Instrument Complement 

Finalized 
(See Appendix B) 

Finalized 
(See Appendix B) 

On-Board Computer 

YES 

YES 

• On-Board Data 
Processing 

NONE 

• . h y 

Some Data Reduction 

• On-Board Data 
Compression 

HONE 

NONE 





Design Goal for 
Unattended Operation 


YES - 24 hours 


Yea - 24 hours 


OF POOR QUALITY 
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SPACE/GRQUND LINK 


Data Acquisition 
Communications 


UARS 

• TDRSS SSA (10 min. contact every 
orbit) (over 24 hour period) 

• GSTDN back-up 


OPEN 

• DSN (Deep Space Network) (Over 12 
hour period) 

• Occasional TDRSS Support 


Telemetry Rates 


• TR playback at 512 Kbps (data 
reversed), science plus engineering 

• Real-time 32 Kbps 

• Engineering only - 1 Kbps 

• (1 Kbps to GSTDN-engineering only) 


IPL GTL EML PPL 
Average ” '4 16 32 64 
(Kbps) 

Playback 94 94 600 600 
(Kbps) 


Conmianding Rates 


1 Kbps nominal 
125 bps emergency 


Not Known 


Telemetry Encoding 


PCM 


PCM 


Telemetry Multiplex 


TDM (firm) 


TDM (Trade-off study to be made) 


AlITVnc) yoOd JO 
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GROUHD SEGMENT ; PRINCIPAL INVESTIGATORS (Pl) 



UARS 

OPEN 

# of Remotes 

19 (Identical) 

42 (Not All Identical) 

# Experiments 

Total 

IPL GTL EML PPL Total 


10+9 TI's 

7 5 9 11 32 + STI's 

Location 

Remote 

Remote 

PI Facility 

• Funded by UARS project 

• Funded by OPEN Project 


• Minicomputer and necessary 
peripherals 

• Minicomputer and necessary 
peripherals 

Software Development 

• To be done by PI for each instrument 

• To be done by PI for each instrument 


• pi's will be provided software 
simulators of UARS/CDHF high speed 
processors 

• pi's will be provided software 
simulators of OPEN/ CDHF high speed 
proces;sors 


•' Testing and integration to take place 
in UARS/CDHF 

• Testing and integration to take 
place in OPEN/ CDHF 

Communications with CDHF 

Via 9 .6 Kb hardwire line • 

Via 9.6 Kb hardwire line 

Compatibility with CDHF 

• Software 

• Software 


- similar operating system 
“ transportability of software 

- similar operating system 

- transportability of software 


• Hardware 

« Hardware 


“ same vendor 

— same vendor 

Facility Hardware 

• Identical 

• 7 mini's 


• Minicomputers 

• 21 Medi's 


• Graphics 

• 14 Maxi's 



• All have graphics 


*n 5JJ 

•O 5 


O 

o 

KJ 


22 > 

i” 


*2 

c 

© 

tr 
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GROUND SEGMENT; CENTRAL DATA HANDLING FACILITY (CDHF) 



UARS 

OPEN 

Dedicated 

YES 

YES 

Function 

UARS data processing and data management 

Open data processing and data management 

Readiness 

3 months prior to launch 

3 months prior to launch 

Raw Data Ingest Volumes 

1.6 X 10^ bits per day 

About 10^® bits (all 4 labs) per day 

Data Accessability 

All pi's and TI's able to access data 
from all UARS instruments 

All pi's, TI's and Cl's able to access 
data from all OPEN instruments 

Data Levels 

Level 0: Raw data 

Level 1: Calibrated data (reversible) 

■Level 2: Data converted to geophysical 

units (irreversible) 

Level 3: Interpolation of geophysical 

parameters onto a common grid 
( irreversible) 

Level 0: Raw data 

Level 1:.; Calibrated data (reversible) 

Level 2:1 Data converted to geophysical 
units (irreversible) 

Routine Level Conversion 
of Data 

Level 0 through Level 3 

• Level 0 to Level 1 

• Level 1 to Level 2 at CDHF and 
remotes 

Analysis 

At remotes 

In CDHF or remotes 

Quick Look Capability 

TBD 

YES (within 8 hours) 

Digital Communications 
with Pi's 

YES (9.6 Kb lines) 

YES (9.6 Kb lines) 


URIQijVSAL 5^ 

OF POOK QUALIW 































GROUND SEGMENT: CENTRAL DATA HANDLING FACILITY (CDHF) (Continued) 



UARS 

OPEN 

Operation 

2 shifts/day, 7 days a week 
(See Appendix C) 

3 shifts/day, 7 days a week 
(See Appendix C) 

Operational Lifetime 

30 months (See Appendix C) 

48 Months (See Appendix C) 

Availability Goal 

2: 99X 

2l 99% 

Processing Capability 

2 MFLOPS/sec Min. Effective (est.) 

9 MFLOPS/sec Min. Effective (est.) 

Maximum Mass Store 
on-line) Data Retention 

Ill Gigabytes 

418 Gigabytes 

Data Availability 

• Level 0 data within 48 hours 

• Level 1 data within 7 days 

• Level :0 data available for quick- 
look within 8 hour after receipt 
of data at CDHF 


• Level 2 data within 10 days 

» Level 1 data within 24 hours 


• Level 3 data within TBD days 

• Level 2 data within 72 hours 

Array Processing 

YES 

YES 

Tracking/ Orbit Computata- 
tion Support 

YES 

YES 

Command Management 

"Mailbox" 

Pre-processing at CDHF (TBD) 





Operation and Control 
Functions 


by MSOCC 

(Instrument related command requests 
will pass through CDHF) 


by MSOCC 

(Instrument related command requests 
will pass through CDHF) 
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GROUND SEGMENT; CENTRAL DATA HANDLING FACILITY (CDHF) (Concluded) 



CARS 

OPEN 

On-Line Retention Period 

• Level 0; 10 days 

• Level 1 : 30 days 

• Level 2; Life of mission + 1 year 

• Level 3: Life of mission + 1 year 

All Level 1 and 2 data for 100 days 

Off-Line Storage 

For all raw and processed data 

• After 100 days to off-line store 

• After 1 year to NSSDC 

Off-Line Storage Req;uire- 
ment Over Mission Lifetime 

399 Gigabytes 

4,553 Gigabytes 

System Redundancy 

• No single point failure 
-('Common elements with OPEN/CDHF) 

• No single point failure 
(Common elements with DARS/CDHF) 

Availability of Other 
Data Bases 

Not Planned 

Not Planned 
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GROUND SEGMENT: DATA CAPTURE FACILITY (DCF 


Dedicated 


Function 


Data Source 


Peak Input Rate 


Output Rate 


UARS 

> OPEN 

YES 

YES (Colocated with CDHF) 

1 < 

« Decommutates data to Level 0 experi- 
ment files 

• Strip raw attitude 

e Send playback engineering to POCC 

t ' 

• Quality check 

• Decommutates data to Level 0 experi- 
ment files (TBD) 

• Strip raw attitude 

• Send playback engineering to POCC 

• Quality check 

NASCOM/TDRSS 

NASCOM/D^, Occassional TDRSS support 

512 Kbps (TBD) 

1 Mbps (TBD) 

TBD 

TBD 



















APPENDi3C“B- 
UARS AND OPEN 
INSTRUMENT SELECTIONS 



UARS INSTRUMENT SUMMARY 


INVESTICATIOB 

IHSTRUHHIT 

II 

IHST1T1ITI0N 

iPCimOIi 

Energotie Pnrticlee 

Particle Environaicnt Monitor 
tPEH) 

J.R, Wlnnlgltarrt 

Southveat Resedreh 
Institute 

Dfillaa, TX 

Ultraviolet Solar 

Solar Ultraviolet Spectral 
Irradiance Honltor isUSIH) 

C.E. Brucckncr 

NRI 

Vsnhington, DC 

Ultraviolet Solar 

Solnr Stellar' Irradionce 
Comparieon Honltor (SOLSTICE) 

Cod. Rottman 

of Colorado 

Boulder, CO 

CHENICAS SPECIES/TEHPERAtURE 

Hicrowavc Etrispion* 
Ra^ioTnet«r . > 

Hicrewove Limb Scanner (HtS) 

J.H. Wntera 

Jet Fropulolon Lab, ^ 

rnasdena, CA 

Infrared Occulotlon 
Rodiometer 

Rdlogen Occdlation Experiment 
(IIALOE) 

J.M. RiioaeU, 111 

Langley Reflearch 
Center 

linmptonp VA 

Infrared Efnie^ion 
Radiotaeter 

Improved Stratopplierlc and neflO” 
pplieric Sounder (ISAHS) 

f, Taylor 

Qxiord 

Oxford, England 

Infrared Enieeion 
Rfldioineter (Cryogenic) 

Cryogenic Limb Array Etaloti 
Spectrometer (CLAES) 

A.E. Roche 

Lockheed 

Palo Alto, CA 

Solar Bockscattcr 
Uttrav inlet Radinmeter 

Solar BacKscatter Ultraviolet 
Experiment (SRtJV) 

Frederick 

Goddard Space Flight 
Center 

Grccnbelt, HD 

VINDS 

Hlclieleon Interfere** 

Hindp and Tonroratorce (VIKTBRS) 

C. TlmlLHer 

HCRS 

Paris, France 

meter 

Fab ty** Perot Intcr- 
fcrctneter 

High Renolutlnn Doppler Imnger 
OlRDI) 

P.B. llajre 

U. of Michigan 

Ann Arbor, HI 


OF POOR QUALITV 



-Oars theoretical investigators 


TI 


Institution 


J« S « Cliun^ 

A, Gadd 

B. M, Cunnold 
M.A. Geller 
W.J. Grove 
J.R. Holton 
A.J, Miller 

C. A, Reber 
RcW. Zurek 


Lawrence Livermore Laboratory 

United Kingdom Meteorological 
Office 

Georgia Tech.. 

Goddard Space Flight Center 
Langley Research Center 
Washington University 
NOAA Meteorological Center 
Goddard Space Flight Center 
Jet Propulsion Laboratory 


Location 

Berkley, California 
London, England 

Atlanta, Georgia 
Greenbelt, Maryland 
Hampton, Virginia 
Seattle, Washington 
Washington, D.C, 
Greenbelt, Maryland 
Pasadena,'. California 
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OPEN INSTRUMENT SUMMARY 


INVESTIGATION 


PPL 


Magnetic Fields 
Electric Fields 
Plasma Waves 
Hot Plasma 

Hot Plasma Composition 
Cold Plasma 
Energetic Particles 
Energetic Particle Comp 
Auroral Imager VIS 
Auroral Imager tfV 
Auroral Imager Xray 


EML 


Magnetic Fields 
Electric Fields 

Plasma Waves 
Hot Plasma 

Hot Plasma Composition 
Cold Plasma 
Energetic Particles 
Energetic Particle Comp 


GTL 


Magnetic Fields 
Electric Fields 
Plasma Waves 
Hot Plasma 

Energetic Particle Comp 


IPL 


Magnetic Fields 
Plasma Waves 
Hot Plasma 

Hot Plasma Composition 
Energetic Particles 
Cosmic Rays 
Gamma Rays 


PI 


J.W. Winnigham 

Mozer 

ShawHan 

Scudder 

She 1 ley 

Chappell 

Higbie';:"’" 

Fritz 

Feldman 

Torr 

Imhof 


McPherron 

Maynard (passive) 

Mcllwain (active) 

Scarf 

Parks 

Burch 

Chappell 

Higbie 

Fritz 


Lapping 
Mozer 
Gurnett 
Frank 
Wil liams 


Behannon 

Kaiser 

Ogilvie 

Gloeckler 

Lin 

McDonald 
Tee gar den 


INSTITUTION 


UCLA 

UC, Berkeley 
U of Iowa 
GSFC 

Lockheed PARC 
MSFC 

Los Alamos SL 
NOAA SEL 
JHU 

Utah State 
Lockheed PARC 


UCLA 

GSFC 

UGj San Diego 
TRW 

U of Washington 
Southwest RI 
MSFC 

Los Alamos SL 
NOAA SEL 


GSFC 

UC, Berkeley 
U of Iowa 
U of Iowa 
NOAA SEL 


GSFC 

GSFC 

GSFC 

U of Maryland 
UC, Berkeley 
GSFC 
GSFC 
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ADDITIONAL INVESTIGATORS 


INVESTIGATION 

THEORY 

M. Ashour-Abdalla 
M. Hudson 
D, Papadopoulos 
F* Rees 
' C, Sonett 

GROUND BASED 

J.- Dudeney 
R. Greenwald 
R. Vondrak 


INSTITUTION 


UCLA 

UC, Berkeley 
D of Maryland 
U of Alaska 
D of Arizona 


NERC/UK 

JHD/APL 

SRI 
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APPENDIX “'C 

- > 

UARS AND OPEN OPERATIONAL SCHEDULES 



C-1 


UARS AND OPEN OPERATIONAL SCHEDULES (UPPER; UARSj LOWER: OPEN) 


CDUF + Renoto Temlnal 
|H/u In rijcc 

-.24 ^18 ‘•IZ 


-6 


bynccn 
Kftdd Inoss 


I 


UARS Uuncli 

j > Konthe After UARS Uunch 

n b 12 


UARS 

Tcml nation 

i 

la 


24 


Terninetu 

CbiiF 

Operation 

* 

30 


1 

1 

1 

1 Shift 

2 Shifts 

2 Shifts 

2 <ililfLa 

2 Shifts 

I or 2 Shlfl K 

! 

1 cr 2 Shifts ! 

a CDUF/Rcmotc ToTninat 

• Slttulatlon 

a Invcaclgntor 

a Investigator 

a Investigator 

Reproccsalng 

“ Roproccs'ilng 

tnCQRrnclon» PI 


Taaka 

Tasks 

Tasks 


1 

1 

bcvclopod S/W transferred 
to COitF, and S/H TciClng 
In emtp 

• Testing 

• Date Valid'' 
At ion 

a Routine 
Processing 

• Bouclnc 
Frocesolng 

> Support Data 
Anolysla ' 

1 

• Support Data 1 
Analyala i 

! 



1 



- Backlog 
Proceoalng 
(If needed 

1 

1 


No Boeklog 


'if 


o 9 

•fl 50 

o ^ 

O 25> 
50 P 

lO T? 

G S 

'p> 0 

I- rsa 


5 


CbItF -I- ROBKitc Terminal 

1[/W In Place Ground 

I Svatcat 

I Renctlncsa 

■24 -18 -U -6 [ 


.PL Launch 

FMf 

PPL 


;GTL Launch 

1 LA'inch 

1 Launch 


I 

1 

' ' Heaths After First Open 

Launch 


6 

12 \& 

24 



AU FlighCA 


Tcrnlnatc 


f Terulnata 


CBIIF 


1 


Opernt lot» 

30 


42 

I 

4R 


1 Shift 

2 Shifts 

2 Shifts 

3 Shifts 

3 Shifts 

3 Shifts 

3 Shifts 

3 Shifts 

1 or 2 Shifts 

1 or 2 Shifts 

a COIIF/Rcnoto Teminel 

a Simulation 

a InvcBtlgstor 

a Invcstlgito* 

a Inveatlgator 

a Invastlgotor 

a Investigator 

a Inveatlgotor 

- Reprocessing 

- Rcprocoselng 

Integration! PI 


Taaka 

Tasks 

Tasks 

Taeka 

Taaka 

Tasks 



Davclopcd S/H tranaferred 










C.0 cniF, nmt SfU 

a Testing 

e Data Valid- 

a Rourliie 

• Reutin« 

a Boutina 

• Routine 

a Routine 

^ Support Pets 

• Support 

Testing In GDHP 


ntiDO (IPI + 

Proccanlng 

Processing 

Froccdslng 

ProccBAlng 

Proceaslng 

Analysis 

Anslysie 



GTL) 

OPL, fiU) 

(IPL, CTL.EHL) 

(All 4 Uba) 

(All 4 Laha) 

(All 4 Lobs] 






a Routine 

a Routine 

a Routine 

a Routine 

a Routine 






Process Ing 

Processing 

Processing 

Pcoceaslng 

Pioceaalng 






(IPL + CTL) 

OPL. Cn.,EML) 

(All 4 Ubu) 

4 Backlog 

and Backlog 






.nnd Data 

and Data 

4 Backlog 

Proeeaaing 

Proceaslng 






\alidation 

Val Idatlon 

Proeeaaing 








<rz} 

(FPL) 







Ko Btiklog 
of IPI + CTL 


No Backlog 
EfiL 


Ho Backlog 
PPL 
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